Bug#904047: eviacam: Please consider using getent instead of sg in maintscript
Control: tags -1 + patch On Wed, Jul 18, 2018 at 11:06:37PM +0200, Andreas Henriksson wrote: > Source: eviacam > Version: 2.1.3-4 [...] > If time permits and I haven't heard anything back I'll consider fixing > this via a NMU while at DebCamp/DebConf. [...] I'm attaching the diff to fix this. It's been piuparts tested. Please tell me if you'd like to incorporate it or if you want me to go ahead with NMU. Regards, Andreas Henriksson diff -Nru eviacam-2.1.3/debian/changelog eviacam-2.1.3/debian/changelog --- eviacam-2.1.3/debian/changelog 2018-04-16 15:23:49.0 +0200 +++ eviacam-2.1.3/debian/changelog 2018-07-31 18:36:55.0 +0200 @@ -1,3 +1,13 @@ +eviacam (2.1.3-4.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Replace sg usage with getent group in maintainerscripts +- note for further improvement: + removing group on purge likely violates common consensus + (See mailinglist thread linked in #228692) + + -- Andreas Henriksson Tue, 31 Jul 2018 18:36:55 +0200 + eviacam (2.1.3-4) unstable; urgency=medium * disable DH_VERBOSE = 1 diff -Nru eviacam-2.1.3/debian/postinst eviacam-2.1.3/debian/postinst --- eviacam-2.1.3/debian/postinst 2018-02-28 16:20:44.0 +0100 +++ eviacam-2.1.3/debian/postinst 2018-07-31 18:36:31.0 +0200 @@ -14,7 +14,7 @@ if [ "$RET" = true ]; then # Create group when necessary - if ! sg "$GROUP" true 2>/dev/null; then + if ! getent group "$GROUP" >/dev/null; then addgroup --system "$GROUP" fi diff -Nru eviacam-2.1.3/debian/postrm eviacam-2.1.3/debian/postrm --- eviacam-2.1.3/debian/postrm 2018-02-28 16:20:44.0 +0100 +++ eviacam-2.1.3/debian/postrm 2018-07-31 18:36:53.0 +0200 @@ -10,7 +10,7 @@ case "$1" in purge) - if sg "$GROUP" true 2>/dev/null; then + if getent group "$GROUP" >/dev/null; then delgroup --quiet --only-if-empty "$GROUP" >/dev/null 2>&1 || true fi ;;
Bug#904050: mlocate: Please consider using getent instead of sg in maintscript
Control: tags -1 + patch On Wed, Jul 18, 2018 at 11:06:59PM +0200, Andreas Henriksson wrote: > Source: mlocate [...] > If time permits and I haven't heard anything back I'll consider fixing > this via a NMU while at DebCamp/DebConf. As we discussed you'd handle this and suggested a slightly different way, but I'm attaching my trivial patch anyway as I've already created and piuparts tested it. My only concern is for this to make it in well in time for buster release. Regards, Andreas Henriksson diff -u mlocate-0.26/debian/changelog mlocate-0.26/debian/changelog --- mlocate-0.26/debian/changelog +++ mlocate-0.26/debian/changelog @@ -1,3 +1,10 @@ +mlocate (0.26-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * Replace sg usage with getent group in mlocate.postinst (Closes: #904050) + + -- Andreas Henriksson Sat, 28 Jul 2018 14:55:03 +0200 + mlocate (0.26-2) unstable; urgency=medium * Add support for nocache(1) to cron.daily. Closes: #711323 diff -u mlocate-0.26/debian/mlocate.postinst mlocate-0.26/debian/mlocate.postinst --- mlocate-0.26/debian/mlocate.postinst +++ mlocate-0.26/debian/mlocate.postinst @@ -10,7 +10,7 @@ --slave /usr/bin/updatedb updatedb /usr/bin/updatedb.mlocate \ --slave /usr/share/man/man8/updatedb.8.gz updatedb.8.gz /usr/share/man/man8/updatedb.mlocate.8.gz -if ! sg "$GROUP" true 2>/dev/null; then +if ! getent group "$GROUP" >/dev/null; then addgroup --system "$GROUP" fi
Bug#228692: User/group creation/removal in package maintainer scripts
Hi,
This is my attempt to unlock the progress on this issue.
I'm going to attempt to first collect what I've picked up both from the
previously mentioned mailinglist thread (and other similar ones) and
what I've seen when reviewing maintainerscripts of packages in the
archive. Hopefully others can speak up if they disagree or think I've
missed a common convention. Later we can attempt to formulate a specific
wording for policy.
## common conventions
users/groups should have an "invalid" prefix to avoid clashes with local
users
- sometimes inconvenient to change username and lots of packages doesn't
do this so should only be recommended when possible, not mandatory.
- Debian- (common, see eg. exim4), D (very rarely used?), and _ (also
used) are suggested prefix.
previously created users should *not* (ever) be removed
- it's much less rare these days but still some packages removes
users/groups they created once the package is purged.
- the problem with removing users/groups (reusing uid/gid) is that files
on filesystem can be owned by them which could lead to possible
security issue.
packages generally relies on adduser to do the work, which is basically
a wrapper to implement common debian conventions around useradd, but it
might not be policys place to explicitly require using a specific tool
like adduser.
Packages commonly check if user/group already exists before calling
adduser to create them. Reason being quiet switch to adduser makes it
'too quiet'. Might be better if adduser just gets fixed with eg.
implementing a '--exists-ok' argument, than documenting the current
convention in policy so should leave some room open for this.
Possibly policy should document some of the things adduser does, just in
case someone attempts to /not/ use adduser (why?).
Writing manual mantainerscript code should always be avoided, because
it's a common source of bugs. There are also other issues like sharing
the same namespace and now being able to remove them. Thus adding users
and group should be avoided. Sometimes there are mechanisms that allow
that which can be used in more cases than is currently well known, so it
might be good if debian policy explicitly states that people should
avoid adding users/groups when possible. An example of a mechanism that
allows not creating static system users/groups is unit file option
DynamicUser=yes from systemd (and likely many others that I'm not aware
of). For further information see:
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#DynamicUser=
http://0pointer.net/blog/dynamic-users-with-systemd.html
## example postinst snippet
### Note that packages also needs to depend on adduser!
NEWUSER="_foo"
NEWGROUP="_bar"
if ! getent group "$NEWGROUP" >/dev/null; then
addgroup --force-badname \
--system "$NEWGROUP"
fi
if ! getent passwd "$NEWUSER" >/dev/null; then
adduser --force-badname \
--system --ingroup "$NEWGROUP" \
--home /nonexistent --no-create-home \
"$NEWUSER"
fi
### if username == groupname it can be simplified
NEWUSERGROUP="_foobar"
if ! getent passwd "$NEWUSERGROUP" && ! getent group "$NEWUSERGROUP"
>/dev/null>/dev/null; then
adduser --force-badname \
--system --group \
--home /nonexistent --no-create-home \
"$NEWUSERGROUP"
fi
--
Regards,
Andreas Henriksson
Bug#685746: Seeking seconds for a patch to deal with remaining issues in this old bug
On Mon, Jul 23, 2018 at 10:45:31AM +0800, Sean Whitton wrote: > control: tag -1 +patch > > Hello, > > Seeking seconds: Seconded. > > diff --git a/policy/ch-relationships.rst b/policy/ch-relationships.rst > index 1eaa422..03f5918 100644 > --- a/policy/ch-relationships.rst > +++ b/policy/ch-relationships.rst > @@ -228,6 +228,10 @@ The meaning of the five dependency fields is as follows: > The ``Recommends`` field should list packages that would be found > together with this one in all but unusual installations. > > +It is not a bug if some things in the package do not work properly > +because the user has not installed packages listed in > +``Recommends``. > + > ``Suggests`` > This is used to declare that one package may be more useful with one > or more others. Using this field tells the packaging system and the > > -- > Sean Whitton Regards, Andreas Henriksson
Bug#459427: Patch seeking seconds on changelog vs. NEWS handling
On Sun, Jul 22, 2018 at 11:35:48AM +0800, Sean Whitton wrote: > control: tag -1 +patch > > Hello all, [...] Thanks for working on this and thanks for including your rationale about the tradeoffs you had to make. While I still retain my aging view on this which isn't perfectly described by your proposal I'll myself take the advice from 'perfect is the enemy of good' and see that we would gain by having these improvements in sooner rather than later. Thus, Seconded. > > diff --git a/policy/ch-docs.rst b/policy/ch-docs.rst > > index 1de221f..1503ed8 100644 > > --- a/policy/ch-docs.rst > > +++ b/policy/ch-docs.rst > > @@ -255,32 +255,48 @@ files may be installed into > > ``/usr/share/doc/package``. > > > > .. _s-changelogs: > > > > -Changelog files > > > > +Changelog files and release notes > > +- > > > > Packages that are not Debian-native must contain a compressed copy of > > the ``debian/changelog`` file from the Debian source tree in > > ``/usr/share/doc/package`` with the name ``changelog.Debian.gz``. > > > > -If an upstream changelog is available, it should be accessible as > > -``/usr/share/doc/package/changelog.gz`` in plain text. If the upstream > > -changelog is distributed in HTML, it should be made available in that > > -form as ``/usr/share/doc/package/changelog.html.gz`` and a plain text > > -``changelog.gz`` should be generated from it using, for example, > > -``lynx -dump -nolist``. If the upstream changelog files do not already > > -conform to this naming convention, then this may be achieved either by > > -renaming the files, or by adding a symbolic link, at the maintainer's > > +If an upstream release notes file is available, containing a summary > > +of changes between upstream releases intended for end users of the > > +package and often called ``NEWS``, it should be accessible as > > +``/usr/share/doc/package/NEWS.gz``. An older practice of installing > > +the upstream release notes as ``/usr/share/doc/package/changelog.gz`` > > +is permitted but deprecated. > > + > > +If there is no release notes file available, but there is an upstream > > +changelog, it should be accessible as > > +``/usr/share/doc/package/changelog.gz``. If there are both upstream > > +release notes and an upstream changelog available, it is recommended > > +to install the former but not the latter. > > + > > +If either of these files are distributed in HTML, they should be made > > +available at ``/usr/share/doc/package/NEWS.html.gz`` and > > +``/usr/share/doc/package/changelog.html.gz`` respectively, and plain > > +text versions ``NEWS.gz`` and ``changelog.gz`` should be generated > > +from them, using, for example, ``lynx -dump -nolist``. > > + > > +If the upstream release notes or changelog do not already conform to > > +this naming convention, then this may be achieved either by renaming > > +the files, or by adding a symbolic link, at the maintainer's > > discretion. [#]_ > > > > All of these files should be installed compressed using ``gzip -9``, as > > they will become large with time even if they start out small. > > > > -If the package has only one changelog which is used both as the Debian > > -changelog and the upstream one because there is no separate upstream > > -maintainer then that changelog should usually be installed as > > -``/usr/share/doc/package/changelog.gz``; if there is a separate upstream > > -maintainer, but no upstream changelog, then the Debian changelog should > > -still be called ``changelog.Debian.gz``. > > +If the package has only one file which is used both as the Debian > > +changelog and the upstream release notes or changelog, because there > > +is no separate upstream maintainer, then that file should usually be > > +installed as ``/usr/share/doc/package/NEWS.gz`` or > > +``/usr/share/doc/package/changelog.gz`` (depending on whether the file > > +is release notes or a changelog); if there is a separate upstream > > +maintainer, but no upstream release notes or changelog, then the > > +Debian changelog should still be called ``changelog.Debian.gz``. > > > > For details about the format and contents of the Debian changelog file, > > please see :ref:`s-dpkgchangelog`. > > -- > Sean Whitton
Bug#884697: Progress
Hello Christian Göttsche, On Fri, Jun 29, 2018 at 12:34:44PM +0200, Christian Göttsche wrote: > ping > > I uploaded a new version (lintian fixes, new std version, updated vcs > fields) to mentors (https://mentors.debian.net/package/logrotate). > Someone any ideas about the piuparts issues I mentioned? > > Otherwise I think the package is stable; its working for me on several > machines. I've looked over the 3.14.0-1 package version and generally everything looks very good to me. I'm appending my review notes about minor things below which might be useful for future improvements none the less. Please tell me if you want me to go ahead with further testing and uploading of the package, or if you already have someone else in mind for this task. Please also mention if you've contacted and what their response have been for the people offering mentorship (like in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887151#17 ). # logrotate WATCH OUT / HEADS UP: - I'm not sure about the current state but this has bitten me in the past. The debhelper systemd integration in the past had no particular knowledge about timer units. That resulted in the service unit for the respective timer unit being both enabled and *started* (or restarted, depending on if the package is newly installed or upgraded) at package installation/configure time. You likely do not want to trigger a logrotate at package installation/upgrade time and delay the entire dpkg operation until it completes. (I imagine some people might have massive logs that might take a very long time.) Please verify if current dh-systemd has improved on this front or if you need to add overrides for logrotate.service to not be started/enabled. I suspect this might very well be fixed now to just not start or enable services which don't have any [Install] section (like logrotate.service, but adding a build-time check to verify upstream doesn't slip one in there might be a useful safety for the future?). Minor things I reacted on that you might want to consider for future package versions: debian/upstream/metadata: - Repository url should have '.git' appended instead of last '/', right? - I think Bug-Database is more revelant for listing issues url instead of using Contact. debian/control: - I'm not sure using github project url in Homepage field is appropriate. It's supposed to be an url relevant for end users AFAIK. eg. github pages url would be suitable (if available, which it doesn't seem to be for logrotate). debian/logrotate.preinst: - how old is this? There are no version checks and I didn't look, but maybe it can be dropped now? The less manual written maintainerscript code the better. debian/logrotate.README.Debian: - this seems pretty outdated info as well considering for buster. Maybe it should also be dropped? debian/rules: - neat, but even better would be line-wrapping configure override using a backslash to put each config option on a separate line for easier reading. debian/tests: - given existance of tests reduces unstable->testing migration delay, this might just be a bit too trivial test to exist alone??? (while at the same time an existing test might be better than no test at all) debian/patches/manpage.patch: - why is this information relevant to put in the manpage? A more general solution would be to describe that apt-file can be used to search for which package contains something. Not suitable to document in specialized manpages like logrotate IMHO. Oh, I see this patch is not listed in series file so not applied. Well, might be another reason to drop it. debian/patches: - I see you've already upstreamed some of your work. I hope you will continue that trend with the remaining patches as well. Regards, Andreas Henriksson
Bug#904069: RFS: xsunpinyin/2.0.3-5 [RC]
Hello GengYu Rao, comments inlined below. On Thu, Jul 19, 2018 at 05:57:42AM +, GengYu Rao wrote: > Package: sponsorship-requests > Severity: important > Dear mentors, > > I am looking for a sponsor for my package "xsunpinyin" > > * Package name: xsunpinyin >Version : 2.0.3-5 [...] > dget -x > https://mentors.debian.net/debian/pool/main/x/xsunpinyin/xsunpinyin_2.0.3-5.dsc<https://mentors.debian.net/debian/pool/main/x/xsunpinyin/xsunpinyin_2.0.3-4.dsc> (^^^ broken!) > > > Changes since the last upload: > > migrate to salsa, and fixed URLs. > > > the repo is here https://salsa.debian.org/input-method-team/xsunpinyin Every commit is quite a mess, which is likely a contributing factor why you missed that you bumped compat from 7 -> 11, which isn't mentioned anywhere, in this commit: https://salsa.debian.org/input-method-team/xsunpinyin/commit/9630740c826b66ca615436283b590c75da62b7ab Such a compat change is something which needs to be carefully reviewed and not even mentioning it in the debian/changelog or in your sponsorship request rings a warning bell for me (and thus I stopped looking for other possible issues). Please consider in the future to spend more time writing useful commit messages, one change per commit, marking "typo" commits with 'Gbp-Dch: ignore' (see man gbp dch), (re)view the changes you're about to commit before doing so (using git commit -v) and finally generate debian/changelog using 'gbp dch --auto' to avoid missing to mention certain changes. It's also good to stay away from whitespace changes all over the place (as done by "helpful editors") as that makes diff/review your work unneccesarily hard. I'm not uploading (atleast in the current state), but hope that my comments was somewhat useful to you. Regards, Andreas Henriksson
Bug#904079: systemd: tmpfiles: cleaning up /tmp at boot breaks things
On Fri, Jul 20, 2018 at 10:51:14AM +0700, Arnaud Rebillout wrote: [...] > Just my two cents: I find this behavior a bit fragile. It means that an > application can't reliably use /tmp during boot time. > > How do we know which application needs to create a temporary file when > they're started? This is internal to the implementation, we can't really > make any assumption on that. To be on the safe-side, then we should > ensure that every service runs after tmpfiles cleaned up /tmp. > > How many services do that at the moment? Let me have a look on my machine: > > $ grep -rn 'After=systemd-tmpfiles' /lib/systemd/ > /lib/systemd/system/rpcbind.service:4:After=systemd-tmpfiles-setup.service > > Only one on my machine, that's not much. It makes me wonder how many > services out there, like console-setup, use /tmp at boot time, without > knowing that there's a risk that systemd-tmpfiles break them. You are over generalizing since you forgot to account for this particular line/setting: https://sources.debian.org/src/console-setup/1.184/debian/console-setup-linux.console-setup.service/#L3 HTH Regards, Andreas Henriksson
Bug#898426: [PATCH] partx: exit with error code when partition read failed
Make sure partx exits with a non-0 return code when it runs into either code-path where getting the partition table failed (or wasn't even attempted because of previous error condition). Change was tested using: touch /tmp/foobar partx -s - /tmp/foobar Previously that was only printing an error/warning message and then exiting with 0, but after this change it exits with 1. Signed-off-by: Andreas Henriksson Reported-by: Juan Céspedes Addresses: https://bugs.debian.org/898426 --- disk-utils/partx.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/disk-utils/partx.c b/disk-utils/partx.c index 3ccd1afad..f895b9be3 100644 --- a/disk-utils/partx.c +++ b/disk-utils/partx.c @@ -1054,7 +1054,9 @@ int main(int argc, char **argv) default: abort(); } - } + } else + rc = 1; + blkid_free_probe(pr); } -- 2.17.1
Bug#900819: gimp: Dependency on liblcms2-2 needs tightening
Hello Michael Deegan, Thanks for your bug report. On Tue, Jun 05, 2018 at 08:40:22PM +0800, Michael Deegan wrote: > Package: gimp > Version: 2.10.2-1 > Severity: minor > > Hello, > > Gimp 2.10's versioned dependency on liblcms2-2 probably needs to be ">= 2.9" > instead of ">= 2.7", as otherwise people cherry-picking from unstable may > see: [...] Recent Gimp needs >= 2.8 and that is specified in the build-dependencies of gimp already. Unfortunately liblcms2 lacks the "Build-Depends-Package: liblcms2-dev" meta-header in debian/liblcms2-2.symbols which means the build-time dependency isn't reflected in the runtime dependency. (See man deb-symbols) Regards, Andreas Henriksson PS. While this might seem as a minor bug, severity is specified by policy and this is actually a 'serious' bug (and thus Release Critical). OTOH I think it's best fixed in liblcms2 instead of gimp >From a67ade1a75c52dffb963a552f44694b53cdd025d Mon Sep 17 00:00:00 2001 From: Andreas Henriksson Date: Tue, 5 Jun 2018 23:16:20 +0200 Subject: [PATCH] Add Build-Depends-Package header to symbols file This will ensure packages specifying a versioned Build-dependency will get an atleast as strict runtime dependency version. See man deb-symbols Closes: #900819 --- debian/liblcms2-2.symbols | 1 + 1 file changed, 1 insertion(+) diff --git a/debian/liblcms2-2.symbols b/debian/liblcms2-2.symbols index 04df057..29d19f4 100644 --- a/debian/liblcms2-2.symbols +++ b/debian/liblcms2-2.symbols @@ -1,3 +1,4 @@ +Build-Depends-Package: liblcms2-dev liblcms2.so.2 liblcms2-2 #MINVER# _cms15Fixed16toDouble@Base 2.2+git20110628 _cms8Fixed8toDouble@Base 2.2+git20110628 -- 2.11.0
Bug#872623: kbd: setmetamode fails with StackSmashing detected
Control: tags 872623 + fixed-upstream On Mon, May 28, 2018 at 09:31:53PM +0200, Andreas Henriksson wrote: > Control: forwarded -1 https://github.com/legionus/kbd/pull/16 > Control: tags -1 + upstream [...] Now merged upstream and will be part of the next upstream release (v2.0.5 ?). https://github.com/legionus/kbd/commit/6613abc26a853293c12f4e146a27606f02c8dd03 Regards, Andreas Henriksson
Bug#732796: Please remove the link from open to openvt
Hello Vitezslav Crhonek, Gürkan Myczko sent the below forwarded message to fedora devel list in May 2017, but it seems there was no followup so I'm trying sending it directly to you as you seem to be the one who has been actively committing to the kbd package in fedora. In summary, some people would like to se "open" command be used for a different purpose than the current decades old compatibility link. Personally I think if/when the link is removed we should make sure it's not reused for anything for multiple releases/years to avoid confusion about it pointing to different things in different things in different distros. What do you think? Is it doable to drop it in Fedora? I'd be willing to drop it in Debian which should trickle down to all derived .deb based distros. Hopefully if you change Fedora the rest of the .rpm world will follow suite. This should make the change pretty universal I think and avoid deviating between different distros. Regards, Andreas Henriksson - Forwarded message from Gürkan Myczko - Date: Wed, 17 May 2017 14:00:52 +0200 From: Gürkan Myczko To: de...@lists.fedoraproject.org Cc: 732...@bugs.debian.org Subject: Please remove the link from open to openvt User-Agent: Roundcube Webmail/1.2.5 Hello, First, I have no relation to Fedora, but I write here because of this bug in Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732796 Would you guys at Fedora feel like it's time to get rid of the symlink /bin/open to make space for xdg-open (for fdo fans) or gopen/openapp (for macOS, GNUstep fans). The name change was like 16 years ago. And I wasn't able to find anything still using /bin/open. Thanks, Myczko - End forwarded message -
Bug#872623: kbd: setmetamode fails with StackSmashing detected
Control: forwarded -1 https://github.com/legionus/kbd/pull/16 Control: tags -1 + upstream Hello, Sorry for the late followup. On Sat, Aug 19, 2017 at 04:08:50PM -0400, alsau...@pragmasoft.com wrote: [...] > Upon closer examination, it appears that the KDGKBMETA IOCTL that > is called by setmetamode.c, is subsequently calling: >put_user (, (int __user*) arg); > > Unfortunately, the argument (ometa) is only declared as "char" in > setmetamode.c. So, in essence, we are asking the kernel to store > an into a user space location that has only been > allocated as a "char". > > I now believe that the appropriate correction is to change the > "char ometa, nmeta;" declaration in setmetamode.c to > "unsigned int ometa, nmeta;". During my testing, this change > eliminated the StackSmashing detection and subsequent traceback. [...] I agree with your analysis. Would be best to discuss this issue upstream, but since the fix seemed obvious I went ahead and submitted https://github.com/legionus/kbd/pull/16 Thanks for your detailed bug report and analysis. Regards, Andreas Henriksson
Bug#900223: [Pkg-kbd-devel] Bug#900223: dumpkeys.1: Some changes in the manual
Hello Bjarni Ingi Gislason, Thanks for your improvements to kbd man pages. Could you please submit these upstream? (Both for #900223 and #900224) Relevant points of contact information for upstream can be found at: http://kbd-project.org/ https://lists.altlinux.org/mailman/listinfo/kbd https://github.com/legionus/kbd (see BUGS section at end of) https://git.kernel.org/pub/scm/linux/kernel/git/legion/kbd.git/tree/README.md Regards, Andreas Henriksson
Bug#899058: ITP: domoticz -- Home automation system
Hello Federico Ceratto, On Fri, May 18, 2018 at 07:33:21PM +0100, Federico Ceratto wrote: > Package: wnpp > Severity: wishlist > Owner: Federico Ceratto <feder...@debian.org> > > * Package name: domoticz [...] > The package will be maintained at https://salsa.debian.org/debian/domoticz [...] Thanks for packaging domoticz. I've not used it myself but I hear good things about it and think it'll be a great addition to the debian archive. I had a quick look at the packaging bits in your git repo and have some questions and comments. Maybe something can be useful for you, but maybe not. Anyway... I see you're using alot of the security features in your service file, great! I wish more packages where better at using these features. I can't help but wonder though if it's not possible for you to use DynamicUser=yes ? You seem to already use some of the strict limitations implied by DynamicUser=yes anyway. Using it would allow you to get away without creating a static system user for your service, but your service also won't be able to create any persistent files (which I don't know if you might need). You also added a 'default' file. Personally I think the only good usage for a default file is with init scripts. Unless I missed something you seem to not have any init script so I don't think that argument applies here. Thus I'd suggest you switch from EnvironmentFile to plainly setting the variables via Environment=. That way users can easily ports via 'systemctl edit ...' the same way they would override any other thing in the service. (Fwiw, I think splitting out the port numbers to an environment variable like you did can be useful even when not using a default file. If the ExecStart line is long and has many different arguments overriding the entire line completely for just a simple port change might be suboptimal for upgrades where you might add, remove or change another unrelated command line argument. Thus being able to just override the environment variable is safer.) Not really willing to take on any (co-)maintainership, but if there's a limited task you think I can help out with don't be shy to ask. (Ofcourse since I'm not a user myself, yet, I'll need help from someone who is to test whatever I implement though.) Regards, Andreas Henriksson PS. You already seem to be very well versed with systemd services but in case you're not already familiar with DynamicUser=yes information about it can be found, except from the systemd documentation ofcourse, at http://0pointer.net/blog/dynamic-users-with-systemd.html
Bug#879669: agetty: use full hardening flags
Control: tags -1 + moreinfo Hello, On Tue, Oct 24, 2017 at 10:13:27AM +0200, Christian Göttsche wrote: > Package: util-linux > Version: 2.30.2-0.1 > Tags: patch security > > Please activate full hardening flags for the agetty binary, e.g. use > `export DEB_BUILD_MAINT_OPTIONS = hardening=+all`. Have you done any testing on how much breakage this causes? What was your testing strategy and how does it make us sure that it's safe to enable these build options? Regards, Andreas Henriksson
Bug#882117: non-assignment options for nfs mounts neither recognized in /etc/fstab nor /etc/nfsmount.conf
Control: reassign -1 nfs-common The nfsmount.conf file, the (no)rdirplus mount option, etc is all part of nfs-common (mount.nfs, etc.) so I suspect that's where you really wanted to report this issue against. I'm thus reassigning it for you. Please supply the relevant information as needed (starting with which version of nfs-common package you're using). Full initial bug report quoted below. Regards, Andreas Henriksson On Sun, Nov 19, 2017 at 07:07:53AM +, Kraus, Sebastian wrote: > Package: mount > Version: 2.29.2-1 > > Dear package maintainers, > > simple (non-assignment) nfs mount options like acl, (no)rdirplus are neither > recognized within /etc/fstab nor /etc/nfsmount.conf. > We need to mount some NFS shares at bootup on our client machines, while > setting the nordirplus option being mandatory > cause of severe caching problems against our nfs servers. > Manually mounting the nfs shares on the commandline recognizes these > non-assignment options. > Manual mounts are not feasible in our case. > > Tested with Debian stretch 4.9.0-4-amd64 #1 SMP Debian 4.9.51-1 (2017-09-28) > x86_64 > > Package: linux-image-4.9.0-4-amd64 Version: 4.9.51-1 . > > > > Regards > > > Sebastian Kraus > > > > > > > > Sebastian Kraus > Team IT am Institut für Chemie > Gebäude C, Straße des 17. Juni 115, Raum C7 > > Technische Universität Berlin > Fakultät II > Institut für Chemie > Sekretariat C3 > Straße des 17. Juni 135 > 10623 Berlin > > > Tel.: +49 30 314 22263 > Fax: +49 30 314 29309 > Email: sebastian.kr...@tu-berlin.de > > >
Bug#877612: fsck: A tiny part of the Spanish translation makes no sense
Control: reassign -1 e2fsprogs On Tue, Oct 03, 2017 at 03:08:17PM +0200, Manolo Díaz wrote: > Package: util-linux-locales > Version: 2.29.2-5 > Severity: minor > Tags: l10n > > Dear Maintainer, > > In my case, for instance, when talking about inodes or blocks, the > 'fsck.ext4 -v' output reads: [...] fsck.ext4 is not part of util-linux, so reassigning. Please provide the necessary information as needed to this bug report. (Starting with which version of e2fsprogs you experienced this with.) Even better would be if you could look up where upstream handles translations and help improve it there and it'll eventually appear in Debian. Regards, Andreas Henriksson
Bug#891812: util-linux: FTBFS on hurd-i386: calls pty_init_slave unconditionally
On Thu, Mar 01, 2018 at 01:55:22AM +0100, Samuel Thibault wrote: > Aaron M. Ucko, on mer. 28 févr. 2018 19:47:40 -0500, wrote: > > login-utils/su-common.c:1427:3: warning: implicit declaration of function > > 'pty_init_slave'; did you mean 'initstate'? > > [-Wimplicit-function-declaration] > > [...] > > ./login-utils/su-common.c:1427: undefined reference to `pty_init_slave' > > IIRC I got a fix commited upstream Your fix should now be part of the latest upload (2.32-0.1), unfortunately there's another problem now. Any chance you can test if by any chance the following upstream commit fixes the (libmount-related) build issue on hurd (or if additional upstream fixing is needed for hurd)? https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=061d1a51097c3c025ff46173f10aa135f9a610d4 (FYI, I've just committed making rfkill linux-any to git.) Regards, Andreas Henriksson
Bug#896944: service: this wrapper script should pass additional options to systemctl(8) when using systemd
Hi,
Not that my opinion really counts, but still
On Thu, Apr 26, 2018 at 11:12:33AM +0200, Michael Biebl wrote:
> On Thu, 26 Apr 2018 16:26:03 +0800 WHR <msl023...@gmail.com> wrote:
[...]
> > The service(8) script should pass additional options, if any after
> > '${ACTION}', to systemctl(8).
[...]
> I'm uncertain about this. If you want all features of systemd/systemctl,
> I think you should use systemctl directly.
> service is more of wrapper which hides the differences between
> alternative init systems (sysv, systemd, openrc) and is sort of the
> least common denominator.
I agree, but on the other hand this is the documented syntax (from
manpage):
service SCRIPT COMMAND [OPTIONS]
Also...
service passes COMMAND and OPTIONS to the init script unmodified.
So I think the patch is technically correct (and thanks submitter for
including a patch!).
This still leaves me torn. While the patch implements the documented
behaviour, but I personally see service as the "portable" command.
By allowing init dependent things to be passed that portability is
broken (and then it provides no value over init dependent equivalents).
I guess the bigger question is: Should the OPTIONS field be deprecated?
Thanks a much bigger task and breaking compatibility for things
that's not in the archive and has to be fixed up by users isn't nice.
I guess the minimum bar if maintainers decide deprecation is the best
is to simply document the deprecation and leave the sysvinit
implementain still functional.
(Maybe to be taken into consideration: How does other distributions
service commands work? We all use different implemations IIRC?!)
Regards,
Andreas Henriksson
Bug#896686: connman: please consider enabling iwd plugin
Source: connman Version: 1.35-6 Severity: wishlist Dear Maintainer, The first official release of iwd is now packaged and available (as of today) in the Debian archive. Note that iwd itself should still be considered quite young and immature (experimental?), but it works for me atleast. The current connman version in sid has a plugin for iwd and the README mentions it can safely be enabled alongside "wifi" (read: wpasupplicant) support. It's said to not be enabled by default because iwd "does not have initial release so far" which is no longer true. (However I'm not sure if iwd has potentially had any changes between the unreleased version the connman plugin was developed against or not.) Please consider enabling the iwd plugin (via --enable-iwd) when building connman to allow for easier testing. In the future you might want to change your 'wpasupplicant' recommends to 'wpasupplicant | iwd' (because alternative recommends are supported nowadays isn't it?). FWIW, I've not done any deeper analysis of exactly how iwd plugin works in connman (as I'm not using connman myself) so you might want to look into that before trusting the claims in the README. Regards, Andreas Henriksson
Bug#895584: ITP: ell -- Embedded Linux library
Hello Nobuhiro Iwamatsu, On Fri, Apr 13, 2018 at 12:57:46PM +0900, Nobuhiro Iwamatsu wrote: [...] > * Package name: ell > Version : 0.4 [...] Out of interest (and since I'm not aware of any other users of ell than iwd), may I ask what your motivation is for packaging ell? FYI I've recently uploaded iwd which is currently in NEW (see also ITP #894537) which currently comes with a bundled version of ell. Any chance you're interested in iwd and would like to help out looking into building it against the system ell once your package is available in the archive? Regards, Andreas Henriksson
Bug#894537: ITP: iwd -- wireless daemon for Linux
Package: wnpp Severity: wishlist Owner: Andreas Henriksson <andr...@fatal.se> * Package name: iwd Version : 0.1 Upstream Author : See AUTHORS * URL : https://git.kernel.org/pub/scm/network/wireless/iwd.git/ * License : LGPL-2.1+ Programming Lang: C Description : wireless daemon for Linux I've prepared initial debian packaging of iwd which is available at: https://salsa.debian.org/debian/iwd Please see the debian/control file for full/official description. Help welcome with improving it! The unofficial one is that iwd is a minimalistic replacement for wpa_supplicant (suitable for embedded). It builds on top of modern linux interfaces (nl80211, cfg80211) and provides a D-Bus API. There are also iwctl and iwmon command line utilities included. This should likely still be considered experimental stage software. Latest upstream development release of NetworkManager provides experimental and disabled-by-default support for iwd. You should also be able to find (upstream) support for it in connman. (co-)maintainers welcome. Regards, Andreas Henriksson
Bug#894443: vim-ctrlp: Please move vim from Depends to Enhances
Package: vim-ctrlp
Version: 1.80-1
Severity: wishlist
Tags: patch
Dear Maintainer,
Please consider moving vim from Depends to Enhances.
I'd like to use vim-ctrlp with neovim (without having to also install
vim).
Rather than adding neovim as an alternative to vim, I'd suggest
using the 'Enhances' field which should be the proper relationship
vim-ctrlp has with vim.
Also note that vim-ctrlp already Recommends vim-addon-manager which
in turn Recommends vim, so normal installs would still pull in
vim anyway.
Patch attached for your convenience.
Regards,
Andreas Henriksson
-- System Information:
Debian Release: buster/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500,
'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.15.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
vim-ctrlp depends on no packages.
Versions of packages vim-ctrlp recommends:
pn vim-addon-manager
vim-ctrlp suggests no packages.
-- no debconf information
diff -Nru vim-ctrlp-1.80/debian/changelog vim-ctrlp-1.80/debian/changelog
--- vim-ctrlp-1.80/debian/changelog 2017-01-23 22:35:06.0 +0100
+++ vim-ctrlp-1.80/debian/changelog 2018-03-30 12:53:06.0 +0200
@@ -1,3 +1,9 @@
+vim-ctrlp (1.80-1+ah0) UNRELEASED; urgency=medium
+
+ * Move vim from Depends to Enhances.
+
+ -- Andreas Henriksson <andr...@fatal.se> Fri, 30 Mar 2018 12:53:06 +0200
+
vim-ctrlp (1.80-1) unstable; urgency=medium
* New upstream release
diff -Nru vim-ctrlp-1.80/debian/control vim-ctrlp-1.80/debian/control
--- vim-ctrlp-1.80/debian/control 2017-01-23 22:35:06.0 +0100
+++ vim-ctrlp-1.80/debian/control 2018-03-30 12:52:52.0 +0200
@@ -8,8 +8,9 @@
Package: vim-ctrlp
Architecture: all
-Depends: vim, ${misc:Depends}
+Depends: ${misc:Depends}
Recommends: vim-addon-manager
+Enhances: vim
Description: fuzzy file, buffer, mru, tag, etc. finder for Vim
CtrlP features:
* written in pure Vimscript
Bug#891834: gnome-disk-utility: gnome-disks sees empty space instead of an existing extended partition
Control: tags -1 + moreinfo Hello, You seem to have a very tightly packed partition layout. Doing that with a DOS partition table might not give you the best compatibility. Also please note that your sda3 starts on the same block as your sda2 ends. On Mon, Mar 19, 2018 at 06:18:15PM +0100, Francesco Potortì wrote: > >> # fdisk -G -l /dev/sda > >[...] > > > >Likely udisks has the wrong information. Please include output from: > >udisksctl dump > > Attached Thanks. > > >Also might be useful to have information for utilities that udisks > >relies on like gdisk, parted, (util-linux) fdisk, etc. > > What kind of information? Version? Partition table listing? > > Please ask and I will try to get back with the required info. Please try to provide useful information yourself if you want to have a chance to find anyone interested in helping you debug this issue. Please try to provide a gnome-disks screenshot and a binary partition table (because I have no idea how to parse that /gnu/ fdisk dump). Regards, Andreas Henriksson
Bug#887243: qa upload of gfxboot
Debdiff attached.
diff -Nru gfxboot-4.5.2-1.1/debian/changelog gfxboot-4.5.2-1.1/debian/changelog
--- gfxboot-4.5.2-1.1/debian/changelog 2014-07-25 20:58:48.0 +0200
+++ gfxboot-4.5.2-1.1/debian/changelog 2018-03-06 17:08:15.0 +0100
@@ -1,3 +1,14 @@
+gfxboot (4.5.2-1.1-6) unstable; urgency=medium
+
+ * QA Upload.
+ * Add e2fsprogs to Recommends, also add reiserfsprogs and xfsprogs to
+Suggests. (Closes: #887243)
+ * Add debian/watch pointing to https://github.com/OpenSUSE/gfxboot
+ * Do dbgsym migration and drop gfxboot-dbg package.
+ * Switch from deprecated Priority: extra to optional.
+
+ -- Andreas Henriksson <andr...@fatal.se> Tue, 06 Mar 2018 17:08:15 +0100
+
gfxboot (4.5.2-1.1-5) unstable; urgency=low
* I don't care anymore, not worth it.. orphaning.
diff -Nru gfxboot-4.5.2-1.1/debian/control gfxboot-4.5.2-1.1/debian/control
--- gfxboot-4.5.2-1.1/debian/control2014-07-25 20:58:37.0 +0200
+++ gfxboot-4.5.2-1.1/debian/control2018-03-06 17:08:15.0 +0100
@@ -1,6 +1,6 @@
Source: gfxboot
Section: misc
-Priority: extra
+Priority: optional
Maintainer: Debian QA Group <packa...@qa.debian.org>
Build-Depends:
debhelper (>= 9),
@@ -20,27 +20,14 @@
Depends:
${misc:Depends},
${shlibs:Depends},
-Suggests: gfxboot-themes
+Recommends: e2fsprogs
+Suggests: gfxboot-themes, reiserfsprogs, xfsprogs
Description: tool to test and create graphical boot logos (runtime)
gfxboot is a tool to test and create graphical boot logos for gfxboot
compliant
boot loaders. Currently, this includes grub, lilo, and syslinux (all
payloads).
.
This package contains the runtime utility.
-Package: gfxboot-dbg
-Section: debug
-Priority: extra
-Architecture: any-amd64 any-i386
-Depends:
- ${misc:Depends},
- gfxboot (= ${binary:Version}),
- gfxboot-dev (= ${binary:Version}),
-Description: tool to test and create graphical boot logos (debug)
- gfxboot is a tool to test and create graphical boot logos for gfxboot
compliant
- boot loaders. Currently, this includes grub, lilo, and syslinux (all
payloads).
- .
- This package contains the debugging symbols.
-
Package: gfxboot-dev
Architecture: any-amd64 any-i386
Depends:
diff -Nru gfxboot-4.5.2-1.1/debian/rules gfxboot-4.5.2-1.1/debian/rules
--- gfxboot-4.5.2-1.1/debian/rules 2014-06-24 16:43:33.0 +0200
+++ gfxboot-4.5.2-1.1/debian/rules 2018-03-06 17:08:15.0 +0100
@@ -93,4 +93,4 @@
dh_install --fail-missing
override_dh_strip:
- dh_strip --dbg-package=gfxboot-dbg
+ dh_strip --dbgsym-migration='gfxboot-dbg (<< 4.5.2-1.1-6~)'
diff -Nru gfxboot-4.5.2-1.1/debian/watch gfxboot-4.5.2-1.1/debian/watch
--- gfxboot-4.5.2-1.1/debian/watch 1970-01-01 01:00:00.0 +0100
+++ gfxboot-4.5.2-1.1/debian/watch 2018-03-06 17:08:15.0 +0100
@@ -0,0 +1,3 @@
+version=4
+opts=filenamemangle=s/.+\/v?(\d\S+)\.tar\.gz/gfxboot-$1\.tar\.gz/ \
+ https://github.com/OpenSUSE/gfxboot/tags .*/v?(\d\S+)\.tar\.gz
Bug#891834: gnome-disk-utility: gnome-disks sees empty space instead of an existing extended partition
On Thu, Mar 01, 2018 at 12:54:11PM +0100, Francesco =?utf-8?Q?Potort=C3=AC?= wrote: > Package: gnome-disk-utility > Version: 3.26.2-2 > Severity: normal > > This is what fdisk says about one of my disks, which is consistent with > what is in /proc/partitions: > > # fdisk -G -l /dev/sda [...] Likely udisks has the wrong information. Please include output from: udisksctl dump Also might be useful to have information for utilities that udisks relies on like gdisk, parted, (util-linux) fdisk, etc. Regards, Andreas Henriksson
Bug#717388: Volunteers needed to work on enabling persistent journal
On Thu, Feb 15, 2018 at 09:31:28AM -0800, Josh Triplett wrote:
> How about this:
>
> systemd-journal-transient ships
> /usr/lib/systemd/journald.conf.d/transient.conf which explcitly disables
> the persistent jorunal by setting Storage=volatile.
>
> systemd-journal-persistent ships
> /usr/lib/systemd/journald.conf.d/persistent.conf which explicitly
> enables the persistent journal by setting Storage=persistent.
Basically inventing a package for a config setting.
Other packages will easily be fooled by this. It's easy to assume
you can just then depend on eg. systemd-journal-persistent and
assume there's actually persistent journal but the admin might
have a setting in /etc/systemd/journald.conf that overrides
the systemd-journal-{transient,persistent} setting.
Maybe it's impossible to satisfy everyone, but my gut feeling is
not great about this. Feels like overengineering. I think we
might need something much "simpler" in the hope that if we invent less
we'll get less stuff wrong. It should also help when we try to sell
our solution to the systemd maintainers (and the general Debian
community).
>
> systemd-journal-syslog Depends on systemd-journal-persistent |
> systemd-journal-transient (so that you *can* still explicitly choose to
> have syslog with transient-only storage, useful for some systems such as
> those with no persistent storage at all) and Conflicts/Provides
> system-log-daemon.
AIUI I don't see the point here. Once you Provides system-log-daemon
you can't have any other system-log-daemon installed (as they conflict
against your provides).
>
> default-system-log-daemon would depend on rsyslog for now, and in the
> future, it could start depending on systemd-journal-syslog instead. (Or
> we could handle it as a virtual package, though that could make upgrades
> harder.)
Regards,
Andreas Henriksson
Bug#717388: Volunteers needed to work on enabling persistent journal
On Thu, Feb 15, 2018 at 09:07:21AM -0800, Josh Triplett wrote: > On Thu, Feb 15, 2018 at 05:14:03PM +0100, Andreas Henriksson wrote: [...] > > - (How to handle updates? Consensus seemed to be towards no change on > >updates.) > > I'm interested in helping with this. > > I think we should *always* provide /var/log/journal, and continue to > configure systemd to not use the persistent journal by default rather > than autodetecting via the existence of /var/log/journal; that way, we [...] Interesting proposal, but how do we handle upgrades in this case? I'm thinking about the (possibly small) group of people who has manually uninstalled (r)syslog and created the directory according to /usr/share/doc/systemd/README.Debian.gz instructions (and rely on autodetection). Maybe a NEWS.Debian entry is enough to tell them they now need to install the package that enables persistant journal, but at the same time there will be those who do not pay enough attention and ends up with no logging what so ever after an upgrade which makes me a bit worried Regards, Andreas Henriksson
Bug#717388: Volunteers needed to work on enabling persistent journal
Mostly for the record... I asked Michael Biebl about this bug report and if it's time to reconsider it for Buster. He mentioned it probably should and that he now sees the journal as being mature and robust enough, but that he does not have time to work on it. The same likely goes for the rest of the Debian systemd maintainers team as well. The main blocker is now thus getting the job done. There where some discussion on irc following this that I'll try to summarize, mostly paraphrasing: The main issue is making sure there's consensus on the change. Implementation wise: - we should make sure to not store logs twice, so (r)syslog daemon should not be part of the default install once this is done. - should /var/log/journal be created by a separate package or not? - Should the package creating /var/log/journal have Provides: system-log-daemon, kernel-log-daemon ? That would make a syslog daemon uninstallable, as all of them Conflict/Provides/Replaces system-log-daemon. Not adding the provides was suggested, but then the rdeps of system-log-daemon (primarily anacron which is part of default install) would pull in a system log daemon and we would have double logging. The discussion was leaning towards all rdeps needing fixing. - (How to handle updates? Consensus seemed to be towards no change on updates.) Are you interested in helping out making this happen? Speak up! (I'm interested to work on this myself, but my time is also quite limited so it might not happen for buster unless others also help out.) system-log-daemon rdeps: $ grep-dctrl -FDepends,Recommends system-log-daemon -sSource:Package < /var/lib/apt/lists/deb.debian.org_debian_dists_unstable_main_binary-amd64_Packages | uniq Package: anacron Package: approx Package: cloudprint Package: fwlogwatch Package: heartbeat Source: inetutils Package: logcheck Source: ltsp Package: lyskom-server Package: nullmailer Package: prelude-lml Package: psad Package: request-tracker4 Source: resource-agents Package: rlinetd Package: snort Package: sympa Package: xinetd Package: zoneminder Regards, Andreas Henriksson
Bug#887278: live-build should depend on e2fsprogs explicitly
On Wed, Feb 14, 2018 at 03:46:12PM +0100, Raphael Hertzog wrote: [...] > I believe this bug can be closed by adding a Suggests dependency. I will > do that in git. Thanks. > > > Would likely be better if we file separate bug reports for separate > > issues, for example this typo will likely always make the ntfs check > > fail but that's offtopic for this bug report: > > https://sources.debian.org/src/live-build/1:20171207/scripts/build/binary_hdd/#L53 > > What typo ? > > ntfs-3g is a valid package Yes. > /sbin/mkfs.ntfs is a path to an existing program Agreed, but that's not what the source code uses. Please read the source again. You'll spot it. ;) [...] Regards, Andreas Henriksson
Bug#887278: live-build should depend on e2fsprogs explicitly
Hello Raphael Hertzog,
thanks for your feedback on the issue
On Thu, Jan 25, 2018 at 04:49:37PM +0100, Raphael Hertzog wrote:
> On Mon, 22 Jan 2018, Andreas Henriksson wrote:
[...]
> > My conclusion is thus that this is a false positive and the bug report
> > should simply be closed.
[...]
> There are multiple calls to mkfs.${MKFS} that have not been detected.
> Some of them are already adequately protected by a "Check_package" call
> but I believe that scripts/build/binary_hdd and scripts/build/source_hdd
> have to be updated.
The source of live-build might well need improvements to deal with
what's inside the chroot it works with, but I don't think that's
the main focus of this bug report. A package relationship of live-build,
could not influence what's available in the chroot (unless I'm
mistaken), so the chroot is out of scope I'd say.
Please also note that e2fsprogs will still be installed on *any* system
where it has not explicitly been removed, even after it's no longer
marked 'Essential: yes'. Thus if the chroot live-build works with is
debootstrapped it'll still have e2fsprogs installed. The main question
for this bug report is 'if e2fsprogs is uninstalled, does live-build
also have to be uninstalled on the same system because of that?'.
Looking again, for places where mkfs is used *outside* the chroot
it seems cases looking at LB_BUILD_WITH_CHROOT being false
and then using mkfs is relevant, like for example this one:
https://sources.debian.org/src/live-build/1:20171207/scripts/build/binary_rootfs/#L187
... but at the same time, the same happens for parted usage
and there's no package relationship specified against parted:
https://sources.debian.org/src/live-build/1:20171207/scripts/build/binary_hdd/#L183
or mkfs.jffs2:
https://sources.debian.org/src/live-build/1:20171207/scripts/build/binary_hdd/#L183
I'm confused about the current status and if we agree or not.
Would likely be better if we file separate bug reports for separate
issues, for example this typo will likely always make the ntfs check
fail but that's offtopic for this bug report:
https://sources.debian.org/src/live-build/1:20171207/scripts/build/binary_hdd/#L53
Would be happy to hear more about if maintainers thinks we need a
dependency or not. It still looks to me like *if* a dependency on
e2fsprogs is warranted, it should come with lots of other dependencies
at the same time (like parted, mtd-utils, etc., etc.).
(I'm happy to help out with work on that, but I'm not going to pick up
live-build maintenance and fix every possible bug in it. My interest is
limited to making e2fsprogs non-essential.)
Regards,
Andreas Henriksson
Bug#887192: singularity-container should depend on e2fsprogs explicitly
Control: tags -1 + confirmed Control: retitle -1 singularity-container should recommend e2fsprogs Hello Afif, Thanks alot for your feedback! On Wed, Feb 14, 2018 at 01:43:42AM -0500, Afif Elghraoui wrote: > I would say it should rather be a Recommends. The old default container > image format was based on ext3. It's still supported, but it's just one > of a few possible options. If ext* is no longer the default, I agree that a recommends might be more suitable. > > If that's no problem to you, we can go ahead and make it happen. Would be great if you could have this fixed ASAP. If you're busy feel free to just ask for help with a non-maintainer upload in the meantime and I'll make it happen. Regards, Andreas Henriksson
Bug#887284: autofs should depend on e2fsprogs explicitly
Control: retitle -1 autofs should build-depend and recommend e2fsprogs Control: tags -1 + confirmed On Sun, Jan 14, 2018 at 08:02:46PM +0100, Helmut Grohne wrote: > Package: autofs [...] > /usr/lib/x86_64-linux-gnu/autofs/mount_ext2.so contains fsck.ext2, fsck.ext3 > and fsck.ext4. According to file it is a ELF 64-bit LSB shared object, > x86-64, version 1 (SYSV) [...] Other filesystem specific mount modules has the package for their respective tools in the Recommends field so I would say that's where e2fsprogs belongs as well. (But someone might decide to make it a stronger Depends just because ext is somehow special.) Additionally the configure script tries to look up the full path for the tools, so e2fsprogs should likely also be added to build-depends to make sure the tools are around and can be detected at build-time. I'm CCing Laurent Bigonville who has done the previous QA upload and also has a pending change in the packaging repository hoping he can upload both of them at the same time. Regards, Andreas Henriksson
Bug#872112: linaro-image-tools NMU uploaded to DELAYED/5
Control: tags -1 + pending
Hello,
I've uploaded the attached debdiff as an NMU to DELAYED/5.
Regards,
Andreas Henriksson
diff -Nru linaro-image-tools-2016.05/debian/changelog
linaro-image-tools-2016.05/debian/changelog
--- linaro-image-tools-2016.05/debian/changelog 2016-09-27 23:43:55.0
+0200
+++ linaro-image-tools-2016.05/debian/changelog 2018-02-13 22:13:39.0
+0100
@@ -1,3 +1,17 @@
+linaro-image-tools (2016.05-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+
+ [ Andreas Henriksson ]
+ * Add fdisk dependency and build-depedency (Closes: #872112)
+ * Add e2fsprogs dependency (Closes: #887174)
+ * Add e2fsprogs build-dependency for test-suite (Closes: #887301)
+
+ [ Nicholas D Steeves ]
+ * Change Recommends: btrfs-tools to btrfs-progs (Closes: #878913)
+
+ -- Andreas Henriksson <andr...@fatal.se> Tue, 13 Feb 2018 22:13:39 +0100
+
linaro-image-tools (2016.05-1) unstable; urgency=medium
* New upstream release. (Closes: #747300, #806068, #820454)
diff -Nru linaro-image-tools-2016.05/debian/control
linaro-image-tools-2016.05/debian/control
--- linaro-image-tools-2016.05/debian/control 2016-09-27 23:43:55.0
+0200
+++ linaro-image-tools-2016.05/debian/control 2018-02-13 22:11:41.0
+0100
@@ -4,6 +4,8 @@
Build-Depends: apt-utils,
debhelper (>= 8.1.3~),
dh-python,
+ e2fsprogs,
+ fdisk | util-linux (<< 2.29.2-3~),
dosfstools,
python (>= 2.6.6-3~),
python-all (>= 2.6.6-3~),
@@ -27,6 +29,8 @@
Architecture: linux-any
Depends: apt-utils,
dosfstools,
+ e2fsprogs,
+ fdisk | util-linux (<< 2.29.2-3~),
gdisk,
parted,
python (>= 2.6.6-3~),
@@ -40,7 +44,7 @@
u-boot-tools | uboot-mkimage,
${misc:Depends},
${python:Depends}
-Recommends: btrfs-tools,
+Recommends: btrfs-progs,
command-not-found,
qemu-user-static | qemu-kvm-extras-static,
udisks2 [linux-any]
Bug#887295: tomb should depend on e2fsprogs explicitly
Control: forwarded -1 https://salsa.debian.org/pkg-security-team/tomb/merge_requests/1 Control: tags -1 + patch Hello, the required change has been sent as a merge request on salsa which seems to be the current home for the packaging of tomb. Looking forward to see the maintainers review, merge and upload this soon. Please speak up if you're busy and would like help with a non-maintainer upload! Regards, Andreas Henriksson
Bug#887240: bootstrap-vz should depend on e2fsprogs explicitly
Control: tags -1 + pending Hello, It seems the bootstrap-vz package has been imported to salsa.debian.org (and had it's repository on alioth removed). The relevant change for this bug report seems to also have been committed: https://salsa.debian.org/cloud-team/bootstrap-vz/commit/157c0270ce95efa0b517a2fb958c1966b3c114a4 I'm thus tagging this bug report pending and hoping the maintainer(s) will be uploading the fixed version soon. Regards, Andreas Henriksson
Bug#887209: debootstick should depend on e2fsprogs explicitly
Hello Etienne Dublé, On Tue, Feb 13, 2018 at 08:16:31PM +0100, Etienne DUBLE wrote: > Hi, > I am the maintainer of debootstick, sorry for the silence. Thanks for your reply now though! > Yes, I uploaded a fixed version at: > https://mentors.debian.net/package/debootstick > My sponsor (Vincent Danjean) should review it shortly. Thanks for this information. If Vincent Danjean is too busy at the moment please feel free to reach out for temporary help with sponsorship! > Is it an urgent matter? I mean, what is the expected date for the > removal of e2fsprogs from essentials? We're aiming at getting this done before buster goes into freeze. For a change to the base system like this, the change (in e2fsprogs package) needs to happen well before the freeze date. There's no strict date for when all the bug reports Helmut filed needs to be done though, but the sooner the better. The most important part is knowing that maintainers have a plan for their package so we can identify the packages which needs help being taken care of. Regards, Andreas Henriksson
Bug#887264: sbuild should depend on e2fsprogs explicitly
On Sun, Jan 14, 2018 at 08:11:17PM +0100, Helmut Grohne wrote: > Package: sbuild [...] > /usr/share/sbuild/create-chroot contains mkfs.ext4 and tune2fs. According to > file it is a Bourne-Again shell script, ASCII text executable [...] The create-chroot script uses the mkfs.ext4 and tune2fs commands if and only if the script is called with the optional volume-group argument specified. I can not find any other part of sbuild that calls the create-chroot script. I'm not sure what the rationale is for installing the script in the location where it's shipped (rathen than just putting it in /usr/sbin or similar). https://anonscm.debian.org/cgit/buildd-tools/sbuild.git/commit?id=18512e3303f56a55841719e393c3e5a4653c9b70 https://anonscm.debian.org/cgit/buildd-tools/sbuild.git/commit/bin/create-chroot?h=debian/unstable=f5c642e0786356ccb58d141dda0dbebf0778227a https://anonscm.debian.org/cgit/buildd-tools/sbuild.git/commit/bin/create-chroot?h=debian/unstable=1dff84941e8294158a1a4346996556d39bcf8d3c https://anonscm.debian.org/cgit/buildd-tools/sbuild.git/commit?h=debian/unstable=a0b923fccf6fea35becb330b47ccd14b9d36b012 Please note that there's also a completely separate sbuild-createchroot command which seems to do a similar job. (Maybe 'create-chroot' is an ancient leftover kept around for legacy reasons?) My conclusion is that a dependency on e2fsprogs is likely not strictly needed. A Recommends or Suggests might be considered, but given e2fsprogs will be installed in *any* system except where the admin has explicitly uninstalled it, I think that gives very little benefit. It would be great to hear from maintainers on this! Regards, Andreas Henriksson
Bug#887262: dtc-xen nmu pending
Control: tags -1 + pending
Hello,
I've uploaded a NMU fixing this bug report. Please see attached debdiff.
Please see lintian warnings for additional work that this package would
likely highly benefit from. For example this one points to something
which seems very peculiar:
W: dtc-xen-firewall: command-with-path-in-maintainer-script postinst:44
/sbin/service
The 'service' command is supposed to be a local administrator command
and maintainer scripts should use invoke-rc.d according to Debian
policy. On the other hand, the invokation is guarded by
if [ -e /etc/redhat-release ] ; then
which will (normally) never be true on Debian. So something funky
is going on here.
Please also see the other thing spotted by lintian which should really
also be fixed.
Regards,
Andreas Henriksson
diff -u dtc-xen-0.5.17/debian/changelog dtc-xen-0.5.17/debian/changelog
--- dtc-xen-0.5.17/debian/changelog
+++ dtc-xen-0.5.17/debian/changelog
@@ -1,3 +1,16 @@
+dtc-xen (0.5.17-1.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+
+ [ Andreas Henriksson ]
+ * Add e2fsprogs dependency (Closes: #887262)
+
+ [ Jeroen Schot ]
+ * updated Dutch translation of the dtc-xen debconf templates
+(Closes: #659704)
+
+ -- Andreas Henriksson <andr...@fatal.se> Tue, 13 Feb 2018 19:39:02 +0100
+
dtc-xen (0.5.17-1.1) unstable; urgency=medium
* Non-maintainer upload.
diff -u dtc-xen-0.5.17/debian/control dtc-xen-0.5.17/debian/control
--- dtc-xen-0.5.17/debian/control
+++ dtc-xen-0.5.17/debian/control
@@ -10,7 +10,7 @@
Package: dtc-xen
Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}, apache2-utils, debconf, rrdtool,
python-soappy, python-crypto, python-sqlite, openssh-server, m2crypto,
debootstrap, openssl, sudo, adduser, sysstat, lsb-base, yum, net-tools, lvm2,
ipcalc, makedev
+Depends: ${misc:Depends}, ${python:Depends}, apache2-utils, debconf, rrdtool,
python-soappy, python-crypto, python-sqlite, openssh-server, m2crypto,
debootstrap, openssl, sudo, adduser, sysstat, lsb-base, yum, net-tools, lvm2,
e2fsprogs, ipcalc, makedev
Recommends: dtc-xen-firewall, sysfsutils
Suggests: xen-utils-common
Description: SOAP daemon and scripts to allow control panel management for Xen
VMs
diff -u dtc-xen-0.5.17/debian/po/nl.po dtc-xen-0.5.17/debian/po/nl.po
--- dtc-xen-0.5.17/debian/po/nl.po
+++ dtc-xen-0.5.17/debian/po/nl.po
@@ -1,21 +1,21 @@
-# SOME DESCRIPTIVE TITLE.
-# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
-# This file is distributed under the same license as the PACKAGE package.
-# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
+# Dutch translation of dtc-xen debconf templates.
+# Copyright (C) 2008-2012 THE PACKAGE'S COPYRIGHT HOLDER
+# This file is distributed under the same license as the dtc-xen package.
+# Bart Cornelis <cob...@skolelinux.no>, 2008.
+# Jeroen Schot <sc...@a-eskwadraat.nl>, 2012.
#
msgid ""
msgstr ""
-"Project-Id-Version: dtc-xen\n"
+"Project-Id-Version: dtc-xen 0.5.15-1\n"
"Report-Msgid-Bugs-To: dtc-...@packages.debian.org\n"
"POT-Creation-Date: 2010-09-29 14:06+\n"
-"PO-Revision-Date: 2008-02-25 19:57+0100\n"
-"Last-Translator: Bart Cornelis <cob...@skolelinux.no>\n"
-"Language-Team: debian-l10n-dutch <debian-l10n-du...@lists.debian.org>\n"
-"Language: \n"
+"PO-Revision-Date: 2012-02-13 12:20+0100\n"
+"Last-Translator: Jeroen Schot <sc...@a-eskwadraat.nl>\n"
+"Language-Team: Debian l10n Dutch <debian-l10n-du...@lists.debian.org>\n"
+"Language: nl\n"
"MIME-Version: 1.0\n"
-"Content-Type: text/plain; charset=utf-8\n"
+"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
-"X-Poedit-Language: Dutch\n"
#. Type: string
#. Description
@@ -26,16 +26,16 @@
#. Type: string
#. Description
#: ../dtc-xen.templates:1001
-#, fuzzy
msgid ""
"Dtc-xen will start it's Python based SOAP server to listen for incoming "
"requests over a TCP socket. A remote application (like the dtc web hosting "
"control panel) can then connect to it in order to start, stop, create and "
"destroy a VPS."
msgstr ""
-"Dtc-xen bindt zich aan een SOAP-Pythonserver (waaraan een dtc-paneel "
-"verbonden kan worden waarmee u een een VPS kunt starten, stoppen, aanmaken, "
-"of vernietigen)."
+"Dtc-xen zal zijn SOAP-Pythonserver opstarten om te luisteren naar "
+"binnenkomende verzoeken op een TCP-socket. Een andere applicatie (zoals het "
+"dtc-webhosting-controlepaneel) kan dan verbinding maken om een VPS te "
+"starten, stoppen, aanmaken of vernietigen."
#. Type: string
#. Description
@@ -163,8 +163,8 @@
"Please enter the kernel version number as it appears with the 'uname -a' "
Bug#887241: faumachine-data should depend on e2fsprogs explicitly
On Sun, Jan 14, 2018 at 08:04:39PM +0100, Helmut Grohne wrote: > Package: faumachine-data [...] > /usr/share/faumachine/experiments/test-fi-smart-step2/gen_results.sh contains > badblocks. According to file it is a POSIX shell script, ASCII text executable > /usr/share/faumachine/experiments/test-fi-smart-step2/generate.in contains > badblocks. According to file it is a ASCII text > /usr/share/faumachine/experiments/test-fi-smart-step2/summary.txt contains > badblocks. According to file it is a ASCII text [...] The package description indicate that FAUmachine is a PC emulatior which does (hardware related) fault injection and can run a test-suite on a machine installed from an iso image. Based on this I would assume the badblocks should be available inside the emulated machines operating system, rather than on the host where faumachine is installed. Thus a package relationship might not be suitable here at all. Would be great to get some feedback on this from the package maintainer who hopefully understands what's going on much better than me. Regards, Andreas Henriksson
Bug#887228: puppet-module-swift should depend on e2fsprogs explicitly
On Sun, Jan 14, 2018 at 08:09:16PM +0100, Helmut Grohne wrote: > Package: puppet-module-swift [...] > /usr/share/puppet/modules.available/swift/manifests/storage/ext4.pp contains > mkfs.ext4. According to file it is a ASCII text [...] https://sources.debian.org/src/puppet-module-swift/9.4.4-1/manifests/storage/ext4.pp/#L36 The above looks like using the mkfs.ext4 command is a crutial part of the functionality provided by this file. I can't find anything else in the source that points to this file actually being used anywhere. As a comparison there's also a xfs.pp in the same directory, but the package does not declare any relationship against xfsprogs. I have no puppet knowledge so it's very hard for me to tell what the correct solution is. Judging from the first part above I'd probably lean towards "better safe then sorry -> add e2fsprogs dep", but given the xfs comparison I'm torn Would be great to hear the maintainers view on this! Regards, Andreas Henriksson
Bug#887218: mock should depend on e2fsprogs explicitly
On Sun, Jan 14, 2018 at 08:08:04PM +0100, Helmut Grohne wrote: > Package: mock [...] > /usr/lib/python3/dist-packages/mockbuild/util.py contains chattr. According > to file it is a C++ source, ASCII text [...] https://sources.debian.org/src/mock/1.3.2-2/py/mockbuild/util.py/#L167 Interestingly the chattr system invokation seems to be used in an exception handler. There seems to be many other ways that may be used to deal with this. The overall function seems to be a helper to remove a directory tree. If chattr is not available this should not have a greater impact than the rmtree function simply not being able to do 'chattr -R -i ...' to try to get a file removed. Other methods should still be tried etc. It does thus not seem vital to have a e2fsprogs dependency. I have no idea how important the util.py file and the rmtree functionality is to mock, which might turn the expectation even lower. As it looks to me mock should at most Recommend e2fsprogs. Would be great to hear maintainers opinion about if this bug report should simply be closed without any action or if a Recommends sounds appropriate. Regards, Andreas Henriksson
Bug#887216: rear should depend on e2fsprogs explicitly
On Sun, Jan 14, 2018 at 08:10:35PM +0100, Helmut Grohne wrote: > Package: rear [...] > /usr/share/rear/conf/GNU/Linux.conf contains e2fsck, fsck.ext2, fsck.ext3, > fsck.ext4, mke2fs, mkfs.ext2, mkfs.ext3, mkfs.ext4 and tune2fs. According to > file it is a ASCII text, with very long lines The commands are listed in the PROGS variable, which also lists commands like ifconfig, etc. and their respective package is not listed in any relationship specified in the package. I'm thus assuming there's no need to explicitly list e2fsprogs either for this occurance. > /usr/share/rear/conf/examples/SLE12-SP1-btrfs-example.conf contains chattr > and lsattr. According to file it is a ASCII text > /usr/share/rear/conf/examples/SLE12-SP2-btrfs-example.conf contains chattr > and lsattr. According to file it is a ASCII text, with very long lines Example files (for Suse?) are likely not important to consider. > /usr/share/rear/format/USB/default/300_format_usb_disk.sh contains tune2fs. > According to file it is a ASCII text > /usr/share/rear/format/USB/default/350_label_usb_disk.sh contains e2label. > According to file it is a ASCII text The above two executes the command and calls the Error function if failing. > /usr/share/rear/layout/prepare/GNU/Linux/130_include_filesystem_code.sh > contains tune2fs. According to file it is a ASCII text The command is both used directly and written to a generate script. > /usr/share/rear/layout/prepare/GNU/Linux/130_include_mount_subvolumes_code.sh > contains chattr. According to file it is a ASCII text The command is written to a generated script. > /usr/share/rear/layout/save/GNU/Linux/230_filesystem_layout.sh contains > chattr, e2label, lsattr and tune2fs. According to file it is a ASCII text Commands are executed directly and there doesn't seem to be any real fault handling. The commands seems to be expected to be in place and work. > /usr/share/rear/skel/default/etc/fstab contains debugfs. According to file it > is a ASCII text [...] This mostly seem to be an example of mounting debugfs filesystem. Not using the debugfs command. My conclusion is based on the above that e2fsprogs should indeed be a dependency. Would be great to hear maintainers view on this! Regards, Andreas Henriksson
Bug#887209: debootstick should depend on e2fsprogs explicitly
Control: tags -1 + pending Hello again, After spending time on analysing and writing a followup on the bug report I noticed the package tracker saying there's a new version in the git repository that claims to have this issue fixed (and the version release to unstable on 31 jan 2018!). I'm thus tagging the bug as pending and hoping we'll soon see the version actually be part of the debian archive. Regards, Andreas Henriksson
Bug#887201: cyrus-common should depend on e2fsprogs explicitly
On Sun, Jan 14, 2018 at 08:03:29PM +0100, Helmut Grohne wrote: > Package: cyrus-common [...] > /usr/lib/cyrus/bin/makedirs contains chattr. According to file it is a POSIX > shell script, ASCII text executable [...] This file is found at debian/cyrus-makedirs in the source and indeed uses the chattr command. The file is renamed/installed via debian/rules as: install debian/cyrus-makedirs $(TMPPKG)/usr/lib/cyrus/bin/makedirs (And then installed in cyrus-common package via debian/cyrus-common.install) The debian/README.Debian refers to cyrus-makedirs in multiple places and among others says: o You can use /usr/sbin/cyrus-makedirs to generate the needed directories [...] .. but there's so such file shipped. It seems like the cyrus-makedirs might have been available under it's original name earlier and only later got renamed/moved into a location where I assume it's executed via a wrapper command (similar to how 'git foo' works). Assuming the wrapper command is 'cyrus' (which seems to align well with a cursory glance at ./debian/cyrus ) the makedirs script might be invoked from the debian/cyrus-common.postinst : if [ -z "$2" ]; then echo -n "cyrus-common: Creating cyrus-imapd directories..." cyrus makedirs --cleansquat echo "done." fi There are also several other places which references cyrus-makedirs and even a cyrus-makedirs.8 manpage. My conlusion is thus that a dependency seems warranted (along with a good cleanup), but given that the package is already RC buggy and has been removed from testing a long time ago and that noone seems to be interested it might simply be better to ask for the package to be removed (from unstable). Would be great to hear from maintainers (or anyone else interested!) about this Regards, Andreas Henriksson
Bug#887209: debootstick should depend on e2fsprogs explicitly
Control: tags -1 + confirmed On Sun, Jan 14, 2018 at 08:03:41PM +0100, Helmut Grohne wrote: > Package: debootstick [...] > /usr/share/debootstick/scripts/create-image/functions contains dumpe2fs, > mkfs.ext4 and resize2fs. According to file it is a ASCII text dumpe2fs and resize2fs are only mentioned in comments. Only mkfs.ext4 is actually used in the codes make_root_fs() function. The make_root_fs function is called from create_formatted_image() (in the same file), and the create_formatted_image function is called twice unconditionally in the main debootstick script. (For comparison mkfs.vfat is also used in the same file and dosfstools is already listed in depends.) > /usr/share/debootstick/scripts/live/init/migrate-to-disk.sh contains > resize2fs. According to file it is a Bourne-Again shell script, ASCII text > executable > /usr/share/debootstick/scripts/live/init/occupy-space.sh contains resize2fs. > According to file it is a POSIX shell script, ASCII text executable [...] It seems both of the above files actually uses resize2fs. (No deeper analysis given the previous file already seem to have made it clear mkfs.ext4 from e2fsprogs is crutial.) My conclusion is thus that a dependency on e2fsprogs should be added. Would be great to hear from maintainers on this... Even if it's just to say that an NMU to take care of this would be appreciated. Regards, Andreas Henriksson
Bug#887222: Bug#887189: golang-github-docker-docker-dev should depend on e2fsprogs explicitly
Hello Tianon, On Mon, Feb 12, 2018 at 09:47:03AM -0800, Tianon Gravi wrote: > I agree that this bug as filed doesn't make much sense, but it does > point to one that does make sense IMO, which would be adding the two > packages mentioned (e2fsprogs and xfsprogs) to Suggests over in > docker.io instead (since there are configurations of Docker where it'd > be appropriate and necessary to have those packages installed). Thanks for your feedback. Since we seem to be in agreement I'll close this bug report (via bcc) and for the record copy #887222 which is the bug report where docker.io dependencies are discussed. Lets continue the discussion in that bug report if needed. Regards, Andreas Henriksson
Bug#887192: singularity-container should depend on e2fsprogs explicitly
On Sun, Jan 14, 2018 at 08:11:26PM +0100, Helmut Grohne wrote: > Package: singularity-container [...] > /usr/lib/x86_64-linux-gnu/singularity/cli/image.create.exec contains > mkfs.ext3. According to file it is a Bourne-Again shell script, ASCII text > executable > /usr/lib/x86_64-linux-gnu/singularity/cli/image.expand.exec contains e2fsck > and resize2fs. According to file it is a Bourne-Again shell script, ASCII > text executable [...] Looks to me like there should be a dependency added here for sure. Would be great to hear from the maintainers on this! Regards, Andreas Henriksson
Bug#887189: golang-github-docker-docker-dev should depend on e2fsprogs explicitly
On Sun, Jan 14, 2018 at 08:05:18PM +0100, Helmut Grohne wrote: > Package: golang-github-docker-docker-dev [...] > /usr/share/gocode/src/github.com/docker/docker/pkg/fsutils/fsutils_linux_test.go > contains mkfs.ext4. According to file it is a ASCII text This file also contains mkfs.xfs but declares no relationship against xfsprogs. > /usr/share/gocode/src/github.com/docker/docker/pkg/mount/mountinfo_linux_test.go > contains debugfs. According to file it is a ASCII text This seems to be a false positive from some kind of mountinfo (/proc/mounts ?) and can likely be ignored. Apart from my first comment I'm not sure how useful it is to declare a dependency in the package shipping go *source* that utilizes a certain command. AIUI building go basically means you end up with something statically linked and the consumer of the go source needs to declare the dependency themselves (or atleast I'm not aware of any way for go packages to propagate dependencies via a substvar or similar). Thus my conclusion is that it's probably best to just close this bug report. Would be great to hear maintainers view on this! Regards, Andreas Henriksson
Bug#887266: initscripts should depend on e2fsprogs explicitly
Maybe it was only me it escaped, but please note that initscripts already Recommends e2fsprogs. Apparently this used to be a Depends but was downgraded to Recommends (in 2009), according to the following debian/changelog entry: * Reduce initscripts dependency on e2fsprogs to recomments and drop the versioned relation, as the version needed (1.32+1.33-WIP-2003.04.14-1) was included in a version before oldstable (Closes: #379340). The rationale is in https://bugs.debian.org/379340 (but please note that some things have changed since this discussion. For example the 'fsck' wrapper is shipped by util-linux these days). Maybe that should be considered good enough to just close this bug report? WDYT? Regards, Andreas Henriksson
Bug#890206: neard: missing files in package
Source: neard Version: 0.16-0.1 Severity: normal Dear Maintainer, It seems since 0.15-0.1 there's been files built which is not shipped in the debian packaging. Atleast that's when systemd(.pc) build-dependency was added to generate the unit file, but it's not shipped. When building the current 0.16-0.1 package dh_missing reports the following files as not installed: dh_missing: usr/bin/nciattach exists in debian/tmp but is not installed to anywhere dh_missing: usr/include/version.h exists in debian/tmp but is not installed to anywhere dh_missing: lib/systemd/system/neard.service exists in debian/tmp but is not installed to anywhere Shipping the neard.service file would mask the neard init.d script by providing a native unit with the same name. Likely the other files should also be shipped in neard-tools and neard-dev. Regards, Andreas Henriksson -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#887174: linaro-image-tools should depend on e2fsprogs explicitly
On Sun, Jan 14, 2018 at 08:07:29PM +0100, Helmut Grohne wrote: > Package: linaro-image-tools [...] > /usr/bin/linaro-android-media-create contains e2label. According to file it > is a Python script, ASCII text executable Seems e2label is only used if the --systemimage command line option was passed. Makes me think a strict dependency might not be required. Either a Recommends or Depends on e2fsprogs is possibly useful though. > /usr/bin/linaro-hwpack-install contains e2fsck. According to file it is a > POSIX shell script, ASCII text executable [...] This file only mentions e2fsck in a code comment that talks about what initramfs-tools is up to. Not sure if what the comment says is true, but if it is then initramfs-tools should have the dependencies it needs in place. (There's also already an open bug report against initramfs-tools see #887211) Would be great to hear the maintainers view on this! Regards, Andreas Henriksson
Bug#887173: obs-build should depend on e2fsprogs explicitly
On Sun, Jan 14, 2018 at 08:08:26PM +0100, Helmut Grohne wrote: > Package: obs-build [...] > /usr/lib/obs-build/build-vm contains mkfs.ext2, mkfs.ext3, mkfs.ext4 and > tune2fs. According to file it is a ASCII text > /usr/lib/obs-build/init_buildsystem contains chattr. According to file it is > a Bourne-Again shell script, ASCII text executable [...] It seems both of these occurances are guarded by the CLEAN_BUILD variable being set, which it seems to only be if you pass the --clean command line option. If set, there's also potential use for xfs and btrfs so their respective packages should likely also be added at the same potential level as e2fsprogs. Potentially it could be argued that xfs and btrfs is less common and should thus be one level below. Given it doesn't seem strictly necessary for the commands to be installed, but likely you want them if it was up to me I might have used Recommends for e2fsprogs and either Recommends or Suggests for xfsprogs, btrfs-tools. If maintainers decides to be more strict and support less variantions using Depends isn't something I'd object to either though. Would be great to hear from maintainers on this! Regards, Andreas Henriksson
Bug#887176: [Resolvconf-devel] Bug#887176: resolvconf should depend on e2fsprogs explicitly
Hi Thomas, On Fri, Jan 26, 2018 at 03:14:01PM +, Thomas Hood wrote: > Hi there, > > Is there any special reason not to add e2fsprogs as a dependency? Not really. If you need it you should definitely add a dependency. If you're refering to my previous comments, then I was just trying to explore all possible theoretical possibilities. I don't think it's useful to complicate things just to be able to avoid a dependency on e2fsprogs, unless you have any particular reason for doing it. Hope to see this issue resolved soon. Regards, Andreas Henriksson
Bug#887188: [PKG-Openstack-devel] Bug#887188: nova-compute should depend on e2fsprogs explicitly
Hello Thomas Goirand, On Wed, Jan 24, 2018 at 01:38:01PM +0100, Thomas Goirand wrote: > Andreas, > > rootwrap is just a wrapper around sudo to improve security. So in this > case, nova-compute really *is* using the above tools, and should depend > on e2fsprogs. I'll push a change with nova-common depending on it. As mentioned I spent very little time on trying to understand what rootwrap is, but it seemed to me like a rootwrap filter would be similar to having a /etc/sudoers rule that included eg. mke2fs. Ff that was the case the sudo package still would not depend on e2fsprogs (It would still be the program actually executing the command that sudoers gives you permission to run that needs the dependency.) but apparently spending 2 seconds is not enough to correctly understand rootwrap for me. :P I fully trust you have a much better understanding of this than me, so thanks for your swift feedback. Looking forward to seeing this fixed soon! Regards, Andreas Henriksson
Bug#887292: libsnapper4 should depend on e2fsprogs explicitly
Hello Hideki Yamane, On Tue, Jan 23, 2018 at 08:59:47PM +0900, Hideki Yamane wrote: [...] > Okay, ext4 support in snapper is still experimental one and it needs > patched kernel + special version of e2fsprogs (available in only > SUSE/openSUSE?) > > Now I would specify --disable-ext4 option since Debian doesn't have > such kernel/e2fsprogs and saying "ext4 support" confuses normal users. Thanks for the feedback here! Very useful information. If there's an option to explicitly disable ext4 support in the build that's probably a good idea to use if only to make it more obvious that it's not supposed to work (yet). > > > > > /usr/lib/x86_64-linux-gnu/libsnapper.so.4.1.0 contains chattr. According > > > to file it is a ELF 64-bit LSB shared object, x86-64, version 1 > > > (GNU/Linux) > > Then, how to ensure to check it as above? > Helmut I guess Helmut just used 'strings' command (and grep) on the binary. Regards, Andreas Henriksson
Bug#887251: postgresql-common should depend on e2fsprogs explicitly
Control: tags -1 + pending On Tue, Jan 23, 2018 at 10:16:24AM +0100, Christoph Berg wrote: [...] > Given that a typical install will probably have e2fsprogs installed > anyway, I guess it won't matter much if we chose Recommends or > Suggests here. I'll go with Recommends as that code path is taken for > basically all users, and the result should be predictable. > > https://salsa.debian.org/postgresql/postgresql-common/commit/d4a4aaad7cbc0796204f3b8cf66b7e8f26454e54 Thanks for the update. I agree with your view. All (normal) installations will have e2fsprogs installed, so specifying a dependency is (unlike normal case) here basically a way to say "if you explicitly remove e2fsprogs on your stupid embedded system or container, then you must also remove my package" (either for technical or non-technical reasons). Regards, Andreas Henriksson
Bug#888291: /usr/sbin/NetworkManager: segfault when adding tc filter rule
Control: tags -1 + upstream fixed-upstream patch
Control: forwarded -1
https://cgit.freedesktop.org/NetworkManager/NetworkManager/patch/?id=27e8fffdb833748dfeb6648b8768c4ef48822841
On Wed, Jan 24, 2018 at 06:54:34PM +0100, Andreas Henriksson wrote:
> Package: network-manager
> Version: 1.10.2-3
> Severity: important
> File: /usr/sbin/NetworkManager
>
> Dear Maintainer,
>
> NetworkManager consistently segfaults when adding a tc filter rule for
> me. Backtrace and the example tc rules I'm trying to test out below.
[...]
I can confirm that the above upstream commit fixes the problem
(and applies cleanly to the debian version). Would be great if
you could include it in your next upload.
Regards,
Andreas Henriksson
diff -Nru network-manager-1.10.2/debian/changelog
network-manager-1.10.2/debian/changelog
--- network-manager-1.10.2/debian/changelog 2018-01-21 19:50:39.0
+0100
+++ network-manager-1.10.2/debian/changelog 2018-01-24 22:44:52.0
+0100
@@ -1,3 +1,10 @@
+network-manager (1.10.2-3+fixtfilter0) UNRELEASED; urgency=medium
+
+ * Add patch fixing tc filter crash from
+
https://cgit.freedesktop.org/NetworkManager/NetworkManager/patch/?id=27e8fffdb833748dfeb6648b8768c4ef48822841
+
+ -- Andreas Henriksson <andr...@fatal.se> Wed, 24 Jan 2018 22:44:52 +0100
+
network-manager (1.10.2-3) unstable; urgency=medium
* secret-agent: construct the dbus proxy for async agent with the correct
diff -Nru
network-manager-1.10.2/debian/patches/platform-fix-crash-hashing-NMPlatformTfiter-and-NMPlatformQdisc.patch
network-manager-1.10.2/debian/patches/platform-fix-crash-hashing-NMPlatformTfiter-and-NMPlatformQdisc.patch
---
network-manager-1.10.2/debian/patches/platform-fix-crash-hashing-NMPlatformTfiter-and-NMPlatformQdisc.patch
1970-01-01 01:00:00.0 +0100
+++
network-manager-1.10.2/debian/patches/platform-fix-crash-hashing-NMPlatformTfiter-and-NMPlatformQdisc.patch
2018-01-24 22:44:52.0 +0100
@@ -0,0 +1,65 @@
+From 27e8fffdb833748dfeb6648b8768c4ef48822841 Mon Sep 17 00:00:00 2001
+From: Thomas Haller <thal...@redhat.com>
+Date: Tue, 12 Dec 2017 10:37:59 +0100
+Subject: platform: fix crash hashing NMPlatformTfilter and NMPlatformQdisc
+
+@kind might be NULL. There are 3 forms of the hash-update functions for
+string: str(), str0(), and strarr().
+
+- str0() is when the string might be NULL.
+- str() does not allow the string to be NULL
+- strarr() is like str(), except it adds a G_STATIC_ASSERT()
+ that the argument is a C array.
+
+The reason why a difference between str() and str0() exists, is
+because str0() hashes NULL different from a "" or any other string.
+This has an overhead, because it effectively must hash another bit
+of information that tells whether a string was passed or not.
+
+The reason is, that hashing a tupple of two strings should always
+yield a different hash value, even for "aa",""; "a","a"; "","aa",
+where naive concatentation would yield identical hash values in all
+three cases.
+
+Fixes: e75fc8279becce29e688551930d85e59e1280c89
+---
+ src/platform/nm-platform.c | 8
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/src/platform/nm-platform.c b/src/platform/nm-platform.c
+index c794970..369effb 100644
+--- a/src/platform/nm-platform.c
b/src/platform/nm-platform.c
+@@ -5320,7 +5320,7 @@ nm_platform_qdisc_to_string (const NMPlatformQdisc
*qdisc, char *buf, gsize len)
+ void
+ nm_platform_qdisc_hash_update (const NMPlatformQdisc *obj, NMHashState *h)
+ {
+- nm_hash_update_str (h, obj->kind);
++ nm_hash_update_str0 (h, obj->kind);
+ nm_hash_update_vals (h,
+obj->ifindex,
+obj->addr_family,
+@@ -5387,17 +5387,17 @@ nm_platform_tfilter_to_string (const NMPlatformTfilter
*tfilter, char *buf, gsiz
+ void
+ nm_platform_tfilter_hash_update (const NMPlatformTfilter *obj, NMHashState *h)
+ {
+- nm_hash_update_str (h, obj->kind);
++ nm_hash_update_str0 (h, obj->kind);
+ nm_hash_update_vals (h,
+obj->ifindex,
+obj->addr_family,
+obj->handle,
+obj->parent,
+obj->info);
+- nm_hash_update_str (h, obj->action.kind);
+ if (obj->action.kind) {
++ nm_hash_update_str (h, obj->action.kind);
+ if (nm_streq (obj->action.kind, NM_PLATFORM_ACTION_KIND_SIMPLE))
+- nm_hash_update_str (h, obj->action.simple.sdata);
++ nm_hash_update_strarr (h, obj->action.simple.sdata);
+ }
+ }
+
+--
+cgit v1.1
+
diff -Nru network-manager-1.10.2/debian/patches/series
network-manager-1.10.2/debian/patches/series
--- network-manager-1.10.2/debian/patches/series2018-01
Bug#888291: /usr/sbin/NetworkManager: segfault when adding tc filter rule
Package: network-manager
Version: 1.10.2-3
Severity: important
File: /usr/sbin/NetworkManager
Dear Maintainer,
NetworkManager consistently segfaults when adding a tc filter rule for
me. Backtrace and the example tc rules I'm trying to test out below.
-->88<->88<--
$ sudo coredumpctl dump
PID: 526 (NetworkManager)
UID: 0 (root)
GID: 0 (root)
Signal: 11 (SEGV)
Timestamp: Wed 2018-01-24 18:46:02 CET (4s ago)
Command Line: /usr/sbin/NetworkManager --no-daemon
Executable: /usr/sbin/NetworkManager
Control Group: /system.slice/NetworkManager.service
Unit: NetworkManager.service
Slice: system.slice
Boot ID: 4f7a28442cbe452d9b2e04a5dea264b6
Machine ID: 0ca30f1374c64ae99923a08d640084f1
Hostname: nyera
Storage:
/var/lib/systemd/coredump/core.NetworkManager.0.4f7a28442cbe452d9b2e04a5dea264b6.526.151681596200.lz4
Message: Process 526 (NetworkManager) of user 0 dumped core.
Stack trace of thread 526:
#0 0x7f808eef0866 __GI___strlen_sse2 (libc.so.6)
#1 0x55f5d436d466 nm_hash_update_str (NetworkManager)
#2 0x55f5d437aa3e nmp_object_hash_update (NetworkManager)
#3 0x55f5d42f93b6 _dict_idx_objs_hash (NetworkManager)
#4 0x7f8090814644 g_hash_table_lookup (libglib-2.0.so.0)
#5 0x55f5d42f9d59 nm_dedup_multi_index_obj_intern
(NetworkManager)
#6 0x55f5d42f9ee3 _add (NetworkManager)
#7 0x55f5d42fa297 nm_dedup_multi_index_add_full
(NetworkManager)
#8 0x55f5d437acf1 _idxcache_update (NetworkManager)
#9 0x55f5d437d079 nmp_cache_update_netlink (NetworkManager)
#10 0x55f5d435bdbd event_valid_msg (NetworkManager)
#11 0x55f5d435d30d event_handler_read_netlink
(NetworkManager)
#12 0x55f5d435e241 delayed_action_handle_READ_NETLINK
(NetworkManager)
#13 0x55f5d435e471 event_handler (NetworkManager)
#14 0x7f8090825dd5 g_main_context_dispatch
(libglib-2.0.so.0)
#15 0x7f80908261a0 n/a (libglib-2.0.so.0)
#16 0x7f80908264b2 g_main_loop_run (libglib-2.0.so.0)
#17 0x55f5d42be789 main (NetworkManager)
#18 0x7f808ee7bf2a __libc_start_main (libc.so.6)
#19 0x55f5d42bedea _start (NetworkManager)
Stack trace of thread 545:
#0 0x7f808ef45e6b __GI___poll (libc.so.6)
#1 0x7f8090826119 n/a (libglib-2.0.so.0)
#2 0x7f809082622c g_main_context_iteration
(libglib-2.0.so.0)
#3 0x7f8090826271 n/a (libglib-2.0.so.0)
#4 0x7f809084d5f5 n/a (libglib-2.0.so.0)
#5 0x7f808f21851a start_thread (libpthread.so.0)
#6 0x7f808ef503ef __clone (libc.so.6)
Stack trace of thread 547:
#0 0x7f808ef45e6b __GI___poll (libc.so.6)
#1 0x7f8090826119 n/a (libglib-2.0.so.0)
#2 0x7f80908264b2 g_main_loop_run (libglib-2.0.so.0)
#3 0x7f8091013ad6 n/a (libgio-2.0.so.0)
#4 0x7f809084d5f5 n/a (libglib-2.0.so.0)
#5 0x7f808f21851a start_thread (libpthread.so.0)
#6 0x7f808ef503ef __clone (libc.so.6)
Refusing to dump core to tty (use shell redirection or specify --output).
-->88<->88<--
export FOOPORT=53000
export FOOIP=1.2.3.4
export INTERFACE=eth0 # change to your actual interface name.
tc qdisc add dev $INTERFACE root handle 1: htb default 10
tc class add dev $INTERFACE parent 1: classid 1:1 htb rate 1000mbit ceil
1000mbit
# default leaf class
tc class add dev $INTERFACE parent 1:1 classid 1:10 htb rate 1000mbit ceil
1000mbit
# leaf class to be used for SF traffic limited to 5mbit
tc class add dev $INTERFACE parent 1:1 classid 1:20 htb rate 5mbit ceil 5mbit
# Put traffic going to Aurix on SF port number in 1:20 leaf class
tc filter add dev $INTERFACE protocol ip parent 1:0 prio 0 u32 \
match ip dport ${FOOPORT} 0x \
match ip dst ${FOOIP}/32 \
flowid 1:20
-->88<->88<--
The segfault happens when running the last command (tc filter ...)
which means my wifi connection goes down and all my network traffic
is dead.
Regards,
Andreas Henriksson
-- System Information:
Debian Release: buster/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500,
'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8,
Bug#887227: lynis should depend on e2fsprogs explicitly
On Sun, Jan 14, 2018 at 08:07:56PM +0100, Helmut Grohne wrote: > Package: lynis [...] > /usr/share/lynis/include/binaries contains lsattr and tune2fs. According to > file it is a POSIX shell script, ASCII text executable, with very long lines [...] It seems this shell script lists directory contents and based on matches like lsattr, tune2fs, and many many others, prints a custom message for that utility. I don't think there's any need to specify a relationship to any of these tools. My conclusion is thus that this bug report should likely just be closed without any other action. Would be great to hear from maintainer what's going on. Regards, Andreas Henriksson
Bug#887184: rsrce should depend on e2fsprogs explicitly
On Sun, Jan 14, 2018 at 08:10:57PM +0100, Helmut Grohne wrote: > Package: rsrce [...] > /usr/bin/rsrce contains chattr. According to file it is a ELF 64-bit LSB > executable, x86-64, version 1 (SYSV) [...] This match seems to come from: https://sources.debian.org/src/rsrce/0.2.2/command.c/#L370 Looking at the hooked up cmd_chattr function it doesn't seem to have anything to do with (launching the) e2fsprogs chattr program. My conclusion is that this bug report can likely just be closed. Would be great to hear the maintainers view on this. Regards, Andreas Henriksson
Bug#887196: kvpm should depend on e2fsprogs explicitly
Control: retitle -1 kvpm should also recommend e2fsprogs On Sun, Jan 14, 2018 at 08:05:54PM +0100, Helmut Grohne wrote: > Package: kvpm [...] > /usr/sbin/kvpm contains dumpe2fs and resize2fs. According to file it is a ELF > 64-bit LSB shared object, x86-64, version 1 (GNU/Linux) [...] The other filesystem specific tools (for non-ext* filesystems) are already listed under Recommends so I assume that should be extended with e2fsprogs. Would be great to hear from the maintainer on this! Regards, Andreas Henriksson
Bug#887214: nomad should depend on e2fsprogs explicitly
On Sun, Jan 14, 2018 at 08:08:14PM +0100, Helmut Grohne wrote: > Package: nomad [...] > /usr/bin/nomad contains debugfs. According to file it is a ELF 64-bit LSB > executable, x86-64, version 1 (SYSV) [...] There doesn't seem to be any match for debugfs in the nomad source, so I assume this comes from some golang library that's statically linked into the binary (possibly golang-github-docker-docker-dev). I'm not sure how or if such dependencies are supposed to automatically propagate. Should the golang dev package inject dependencies into misc:Depends or are this supposed to be manualy handled by the consuming application (which I would think leads to massive amount of bugs/mistakes as most manual things which doesn't give an obvious failure when you get it wrong). Would be great to get some feedback from the maintainer on this! Regards, Andreas Henriksson
Bug#887249: fsarchiver should depend on e2fsprogs explicitly
On Sun, Jan 14, 2018 at 08:04:43PM +0100, Helmut Grohne wrote: > Package: fsarchiver [...] > /usr/sbin/fsarchiver contains e2fsck, mke2fs and tune2fs. According to file > it is a ELF 64-bit LSB shared object, x86-64, version 1 (SYSV) [...] The commands are all used in the extfs_mkfs function: https://sources.debian.org/src/fsarchiver/0.8.3-3/src/fs_ext2.c/#L145 Which in turn are called from the ext[234]_mkfs wrapper functions: https://sources.debian.org/src/fsarchiver/0.8.3-3/src/fs_ext2.c/#L92 Those functions are hooked up at: https://sources.debian.org/src/fsarchiver/0.8.3-3/src/filesys.c/#L49 Given that all non-ext* filesystems in that table are listed under Suggests I would guess e2fsprogs should be added to Suggests. (Or possibly promoted as ext being the favourite child to Recommends.) Would be great to hear the maintainers view on this... Regards, Andreas Henriksson
Bug#887191: python3-tempest should depend on e2fsprogs explicitly
On Sun, Jan 14, 2018 at 08:10:21PM +0100, Helmut Grohne wrote: > Package: python3-tempest [...] > /usr/lib/python3/dist-packages/tempest/common/utils/linux/remote_client.py > contains mke2fs. According to file it is a C++ source, ASCII text [...] Since both python-tempest and python3-tempest is built from the same source and both seems to have exactly the same symptoms I'm replying to both at the same time. >From remote_client.py: def make_fs(self, dev_name, fs='ext4'): cmd_mkfs = 'sudo /usr/sbin/mke2fs -t %s /dev/%s' % (fs, dev_name) Please note how mke2fs is invoked with a full path. On Debian the mke2fs utility doesn't live in that path (unless you're converted to usrmerge, but packages not assume users have done that - atleast not without a dependency on the usrmerge conversion package). Correct path in e2fsprogs package is: /sbin/mke2fs On top of this, the invokation of the make_fs function is done in manager.py an looks like this: ssh_client.make_fs(dev_name) This makes me assume that the command is executed on a remote host over ssh. (Which should have already been obvious since the previous source file contained the word 'remote' in it.) A local dependency (or other package relationship) will not help what's available and installed on the remote host. My conclusion is thus that this bug report should likely just be closed. (Or repurposed as a bug report about the incorrect path.) Regards, Andreas Henriksson
Bug#887188: nova-compute should depend on e2fsprogs explicitly
On Sun, Jan 14, 2018 at 08:08:22PM +0100, Helmut Grohne wrote: > Package: nova-compute [...] > /etc/nova/rootwrap.d/compute.filters contains e2fsck, mkfs.ext3, mkfs.ext4, > resize2fs and tune2fs. According to file it is a ASCII text [...] My understanding after spending about 2 seconds looking at the initial part of https://wiki.openstack.org/wiki/Rootwrap is that nova-compute likely doesn't execute these commands itself. I would thus assume neither of Depends, Recommends or Suggests is suitable in this case and the bug report should simply be closed. Would be great to hear maintainers view on this. Regards, Andreas Henriksson
Bug#887177: spacefm-gtk3 should depend on e2fsprogs explicitly
On Sun, Jan 14, 2018 at 08:11:39PM +0100, Helmut Grohne wrote: > Package: spacefm-gtk3 [...] > /usr/bin/spacefm contains tune2fs. According to file it is a ELF 64-bit LSB > shared object, x86-64, version 1 (SYSV) [...] Since this package seems to be built from the same source and suffer from the exact same condition as spacefm, please please see analysis in http://bugs.debian.org/887257 Regards, Andreas Henriksson
Bug#887257: spacefm should depend on e2fsprogs explicitly
See also http://bugs.debian.org/887177
Bug#887230: ocsinventory-agent should depend on e2fsprogs explicitly
On Sun, Jan 14, 2018 at 08:08:31PM +0100, Helmut Grohne wrote: > Package: ocsinventory-agent [...] > /usr/share/perl5/Ocsinventory/Agent/Backend/OS/AIX/CPU.pm contains lsattr. > According to file it is a Perl5 module source, ASCII text > /usr/share/perl5/Ocsinventory/Agent/Backend/OS/AIX/Mem.pm contains lsattr. > According to file it is a Perl5 module source, ASCII text > /usr/share/perl5/Ocsinventory/Agent/Backend/OS/AIX/Networks.pm contains > lsattr. According to file it is a Perl5 module source, ASCII text > /usr/share/perl5/Ocsinventory/Agent/Backend/OS/AIX/Storages.pm contains > lsattr. According to file it is a Perl5 module source, ASCII text > /usr/share/perl5/Ocsinventory/Agent/Backend/OS/Linux/Drives.pm contains > dumpe2fs. According to file it is a Perl5 module source, ASCII text [...] These results looks suspiciously similar to fusioninventory-agent. See http://bugs.debian.org/887276 vs http://bugs.debian.org/887230 Regards, Andreas Henriksson
Bug#887231: dnssec-trigger should depend on e2fsprogs explicitly
On Sun, Jan 14, 2018 at 08:03:54PM +0100, Helmut Grohne wrote: > Package: dnssec-trigger [...] > /usr/lib/dnssec-trigger/dnssec-trigger-script contains chattr. According to > file it is a Python script, UTF-8 Unicode text executable > /usr/sbin/dnssec-triggerd contains chattr. According to file it is a ELF > 64-bit LSB shared object, x86-64, version 1 (SYSV) [...] These occurances can be found in the source at: https://sources.debian.org/src/dnssec-trigger/0.13-6/riggerd/reshook.c/#L114 https://sources.debian.org/src/dnssec-trigger/0.13-6/dnssec-trigger-script.in/#L528 Both of them does indeed seem to execute the chattr command (with -i or +i to set/unset immutable flag). Both of them also doesn't seem to care very much about errors from executing the command (and one is even called _try_*). I would assume this means it's not critical for the command to actually exist and a Recommends relationship or lower against e2fsprogs is enough. Would be great to hear what maintainers think about this. Regards, Andreas Henriksson
Bug#887232: virt-sandbox should depend on e2fsprogs explicitly
On Sun, Jan 14, 2018 at 08:12:17PM +0100, Helmut Grohne wrote: > Package: virt-sandbox [...] > /usr/lib/python2.7/dist-packages/libvirt_sandbox/image/sources/base.py > contains mkfs.ext3. According to file it is a Python script, UTF-8 Unicode > text executable [...] The use of mkfs.ext3 is found here: https://sources.debian.org/src/libvirt-sandbox/0.5.1+git20160404-1/libvirt-sandbox/image/sources/base.py/#L138 As can be seen /sbin/mkfs.ext3 is passed as an *argument* to the virt-sandbox command. I assume mkfs.ext3 is executed inside some sort of sandbox. A dependency would make sure the command is available *outside* the sandbox, but I have no idea if this benefits what's run *inside* the sandbox in any way Would be great to hear the maintainers view on this. Regards, Andreas Henriksson
Bug#887236: xen-tools should depend on e2fsprogs explicitly
Hello Axel Beckert, Thanks for your feedback! On Mon, Jan 22, 2018 at 10:52:09PM +0100, Axel Beckert wrote: > Control: severity -1 important > Control: retitle -1 xen-tools: should recommend e2fsprogs > > Hi Andreas and Helmut. > > Helmut: Thanks for the bug report! > > Andreas Henriksson wrote: > > Control: severity -1 minor > > I don't see why a missing package relation should be minor. Until > e2fsprogs isn't non-essential, it's at least not "serious". [...] >From my point of view given that e2fsprogs now and also in the future will be part of every normal installation, the only thing that makes any difference if there's a missing *dependency* relationship. When the relationship should rather be Recommends or Suggests it might be seen as better to be explicit about that thus the minor severity. The change would be mostly theoretical and informational. (You might be right that ext* is worthy of a special bump to Recommends.) Ofcourse, seeing the bug report fixed would be much better than arguing over its severity though Hopefully now that we've discussed all this we can see the change swiftly uploaded. Regards, Andreas Henriksson
Bug#887234: python-cgcloud-core should depend on e2fsprogs explicitly
On Sun, Jan 14, 2018 at 08:09:21PM +0100, Helmut Grohne wrote: > Package: python-cgcloud-core [...] > /usr/lib/python2.7/dist-packages/cgcloud/core/cloud_init_box.py contains > mkfs.ext4. According to file it is a C++ source, ASCII text [...] The mkfs.ext4 command is used in the following two places: https://sources.debian.org/src/python-cgcloud/1.6.0-1/core/src/cgcloud/core/cloud_init_box.py/#L117 https://sources.debian.org/src/python-cgcloud/1.6.0-1/core/src/cgcloud/core/cloud_init_box.py/#L137 As can be seen the code also uses commands from the following packages without declaring any package relationship towards them: mount: mount mdadm: mdadm initramfs-tools: update-initramfs etc... Given none of the other commands are listed anywhere, there doesn't seem to be a big need to be explicit about just e2fsprogs. Possibly a bigger package review is needed to find and explicitly note the relationship to other packages, or maybe there simply isn't any need for the affected code. Feedback from maintainers on this would be greatly appreciated. Regards, Andreas Henriksson
Bug#887236: xen-tools should depend on e2fsprogs explicitly
Control: severity -1 minor Control: retitle -1 xen-tools should also suggest e2fsprogs On Sun, Jan 14, 2018 at 08:12:31PM +0100, Helmut Grohne wrote: > Package: xen-tools [...] > /usr/bin/xen-create-image contains mkfs.ext2, mkfs.ext3 and mkfs.ext4. > According to file it is a Perl script text executable [...] The ChangeLog mentions these tools added as 'optional', so likely a dependency is not the right thing here. Right next to the mkfs.ext* commands we find the reiserfs and xfs equivalents, and reiserfsprogs and xfsprogs are listed under Suggests relationship. My conclusion is thus that adding e2fsprogs to Suggests seem to be the proper fix. Regards, Andreas Henriksson
Bug#887237: glusterfs-common should depend on e2fsprogs explicitly
On Sun, Jan 14, 2018 at 08:05:13PM +0100, Helmut Grohne wrote: > Package: glusterfs-common [...] > /usr/lib/x86_64-linux-gnu/glusterfs/3.13.0/xlator/mgmt/glusterd.so contains > tune2fs. According to file it is a ELF 64-bit LSB shared object, x86-64, > version 1 (SYSV) [...] The source code matches for tune2fs are found here: https://sources.debian.org/src/glusterfs/3.13.0-1/xlators/mgmt/glusterd/src/glusterd-utils.c/#L6525 https://sources.debian.org/src/glusterfs/3.13.0-1/xlators/mgmt/glusterd/src/glusterd-snapshot.c/#L5094 As can be seen right next to it there's also support for xfs filesystem using both xfs_info and xfs_admin command, but the package specifies no relationship towards xfsprogs. This might be an indication that no e2fsprogs relationship is needed either, or it just means there are multiple mistakes Would be great to hear what maintainers thinks about this! Regards, Andreas Henriksson
Bug#887242: euca2ools should depend on e2fsprogs explicitly
On Sun, Jan 14, 2018 at 08:04:27PM +0100, Helmut Grohne wrote: > Package: euca2ools [...] > /usr/lib/python2.7/dist-packages/euca2ools/commands/bundle/bundlevolume.py > contains tune2fs. According to file it is a C++ source, ASCII text [...] The INSTALL file contains this very helpful information: -8<--->88<>8--- The euca-bundle-vol command only works on Linux. It requires the utilities for creating and managing the filesystem to be bundled (e.g. mkfs and tune2fs) as well as these additional executables: - blkid - dd - gzip or pigz - kpartx - losetup - mkfs - mount - openssl >= 1 - parted - rsync - sgdisk - sync - umount For specific package names for these dependencies, check the distribution-specific sections below. -8<--->88<>8--- (The distribution-specific section talks about ubuntu 12.04 so likely not very useful to us because of being outdated.) Given that (after ignoring the tools part of Essential) basically none of the packages containing these tools are mentioned in any package relationship from euca2ools package, either there's a major problem with the packaging or more likely this tool is not particularly important compared to other things in the same package. Fwiw, the following commands are part of Essential: yes packages and thus there should be no dependency for them: blkid, dd, gzip, mkfs (but based on -t arguments external helpers might be needed as dependencies), sync The others are part of the following packages: kpartx: kpartx mount: losetup, mount, umount openssl: openssl parted: parted rsync: rsync gdisk: sgdisk See also the "Notes for Distributors" section. Would be great to hear from maintainers what their thoughts is on this... My conclusion is that there likely is no need for e2fsprogs specific care here, but reviewing the package from a bigger perspective might be useful. Regards, Andreas Henriksson
Bug#887243: gfxboot should depend on e2fsprogs explicitly
On Sun, Jan 14, 2018 at 08:05:04PM +0100, Helmut Grohne wrote: > Package: gfxboot [...] > /usr/bin/gfxboot contains tune2fs. According to file it is a Perl script text > executable [...] It indeed seems like gfxboot will launch both mkfs.ext[23] and tune2fs when the filesystem is ext2 or ext3 (while ext4 falls under 'unsupported filesystem'). https://sources.debian.org/src/gfxboot/4.5.2-1.1-5/gfxboot/#L382 Apart from ext2/ext3 gfxboot also seems to support reiserfs (but not reiser4), xfs and fat filesystems but there's no package relationship specified to any of reiserfsprogs, xfsprogs or dosfstools either. Would be great to hear from maintainers if all of them missing is a mistake or if maybe there's no need for a relationship against e2fsprogs either. Regards, Andreas Henriksson
Bug#887251: postgresql-common should depend on e2fsprogs explicitly
On Sun, Jan 14, 2018 at 08:09:11PM +0100, Helmut Grohne wrote: > Package: postgresql-common [...] > /usr/bin/pg_createcluster contains chattr. According to file it is a Perl > script text executable [...] For a start I guess it begs to be asked if the users who has postgresql-common package installed are likely to ever use the pg_createcluster script at all... based on that alone a Depends might not be warranted. Looking at the code we'll find the following use of chattr: # disable copy-on-write semantics for PostgreSQL data on btrfs and similar; # this fails on file systems which don't support it, so ignore errors system "chattr +C '$datadir' 2>/dev/null"; https://sources.debian.org/src/postgresql-common/189/pg_createcluster/#L62 This doesn't make me feel a dependency is warranted. Possibly a Recommends or Suggests. Even just closing this bug report with no action could seem like the proper response to me. Would be great to hear maintainers view on this. Regards, Andreas Henriksson
Bug#887256: openstack-deploy should depend on e2fsprogs explicitly
On Sun, Jan 14, 2018 at 08:08:40PM +0100, Helmut Grohne wrote: > Package: openstack-deploy [...] > /usr/sbin/openstack-deploy-tempest contains mkfs.ext4. According to file it > is a POSIX shell script, ASCII text executable [...] It indeed seems like mkfs.ext4 is (conditionally) used. It also seems like mkfs.xfs is (conditionally) used, but there's no package relationship specified against xfsprogs either. https://sources.debian.org/src/openstack-meta-packages/0.18/src/openstack-deploy-tempest/?hl=312#L312 https://sources.debian.org/src/openstack-meta-packages/0.18/src/openstack-deploy-tempest/?hl=352#L352 https://sources.debian.org/src/openstack-meta-packages/0.18/src/openstack-deploy-tempest/?hl=332#L332 https://sources.debian.org/src/openstack-meta-packages/0.18/saio/bin/resetswift/?hl=12#L12 Would be great to hear maintainers view on this... Regards, Andreas Henriksson
Bug#887257: spacefm should depend on e2fsprogs explicitly
Control: severity -1 minor On Sun, Jan 14, 2018 at 08:11:35PM +0100, Helmut Grohne wrote: > Package: spacefm [...] > /usr/bin/spacefm contains tune2fs. According to file it is a ELF 64-bit LSB > shared object, x86-64, version 1 (SYSV) [...] The tune2fs usage is to be found in the code at: https://sources.debian.org/src/spacefm/1.0.5-2/src/settings.c/#L10724 At the same place you'll also find other commands like mlabel (from mtools), /sbin/ntfslabel (from ntfs-3g), /sbin/btrfs (which no package in Debian ships but btrfs-progs ships /bin/btrfs !!!), /sbin/reiserfstune (from reiserfsprogs), /usr/bin/udevil (from udevil), etc. Except for udevil which is listed in Suggests, none of the others are mentioned in current package relationships. All of them seems to be used to populate some developer menu which makes me think they might not be part of the normal use for this application: https://sources.debian.org/src/spacefm/1.0.5-2/src/settings.c/#L10636 My conclusion is thus that it seems fairly safe to guess that at most it might be warranted to put e2fsprogs in Suggests. Possibly just closing the bug report with no other action taken. Would be great to hear from maintainer(s) if they think my conclusion sounds reasonable. Regards, Andreas Henriksson
Bug#887260: drobo-utils should depend on e2fsprogs explicitly
On Sun, Jan 14, 2018 at 08:04:12PM +0100, Helmut Grohne wrote: > Package: drobo-utils [...] > /usr/lib/python2.7/dist-packages/Drobo.py contains mke2fs. According to file > it is a Python script, ASCII text executable, with very long lines The mke2fs command is found in a function called 'format_script' which according to it's description only returns a script that formats a LUN according to given parameters. One of them being filesystem type so ext* is only one case among several. The script seems to be written to a file and the path returned. The path is hardcoded file in /tmp which likely means drobo-utils suffers from a tempfile vulnerability: https://sources.debian.org/src/drobo-utils/0.6.1+repack-2/Drobo.py/#L369 Apart from ext* there's also support for ntfs or FAT32/msdos filesystems which results in the commands mkntfs or mkdosfs being used instead of mke2fs. There's no relationship specified against ntfs-3g or dosfstools so I guess either there's no need a e2fsprogs relationship or all three of them are missing. Would be great to hear from maintainers how they view this > /usr/lib/python2.7/dist-packages/DroboGUI.py contains mke2fs. According to > file it is a Python script, ASCII text executable, with very long lines [...] This more or less could be considered a false positive. The gui seems to run 'which mke2fs' and if there's no result the following text is shown: 'Ext3 disabled (missing mke2fs)' (Similar code also available for dos and ntfs.) Given that the GUI is the only thing using the format_script function and the GUI seems to disable using filesystems for which a tool is not available, my conclusion would be that at most a Recommends is warranted (for all three of e2fsprogs, dosfstools, ntfs-3g). Again would be great to hear from maintainers what their view on this is Regards, Andreas Henriksson
Bug#887265: note should depend on e2fsprogs explicitly
Control: severity -1 minor On Sun, Jan 14, 2018 at 08:08:18PM +0100, Helmut Grohne wrote: > Package: note [...] > /usr/bin/note contains chattr. According to file it is a Perl script text > executable [...] Both occurances of chattr in the source is decorated with a comment stating "ignore errors": https://sources.debian.org/src/note/1.3.22-1/bin/note/#L726 https://sources.debian.org/src/note/1.3.22-1/bin/note/#L881 The attribute that tries to be set is 'secure delete'. My conclusion is thus that the need for chattr is very limited and would warrant at most a Suggests: e2fsprogs. Possibly not even that and just closing this bug report without any changes. Would be great to hear from the maintainer(s) what they think of this. Regards, Andreas Henriksson
Bug#887276: fusioninventory-agent should depend on e2fsprogs explicitly
On Sun, Jan 14, 2018 at 08:04:47PM +0100, Helmut Grohne wrote: > Package: fusioninventory-agent [...] > /usr/share/fusioninventory/lib/FusionInventory/Agent/Task/Inventory/AIX/CPU.pm > contains lsattr. According to file it is a Perl5 module source, ASCII text > /usr/share/fusioninventory/lib/FusionInventory/Agent/Task/Inventory/AIX/Memory.pm > contains lsattr. According to file it is a Perl5 module source, ASCII text > /usr/share/fusioninventory/lib/FusionInventory/Agent/Task/Inventory/AIX/Networks.pm > contains lsattr. According to file it is a Perl5 module source, ASCII text > /usr/share/fusioninventory/lib/FusionInventory/Agent/Task/Inventory/AIX/Storages.pm > contains lsattr. According to file it is a Perl5 module source, ASCII text > /usr/share/fusioninventory/lib/FusionInventory/Agent/Task/Inventory/Linux/Drives.pm > contains dumpe2fs. According to file it is a Perl5 module source, ASCII text [...] I'm going to assume all the AIX files only applies to AIX systems, and is thus not relevant in a Debian context. This leaves Linux/Drives.pm and indeed it uses dumpe2fs, but (as it seems) only if it's available: https://sources.debian.org/src/fusioninventory-agent/1:2.3.16-1/lib/FusionInventory/Agent/Task/Inventory/Linux/Drives.pm/#L53 This makes me think e2fsprogs should not be a Depends, but possibly a Recommends or Suggests. As can be seen near the same location in the code, there's also support for xfs and dos/vfat filesystems. There's no relationship specified against xfsprogs or dosfstools, so I'm guessing either there's no need for e2fsprogs relationship or all three are missing from Recommends or Suggests. Would be great to hear from maintainers on this Regards, Andreas Henriksson
Bug#887278: live-build should depend on e2fsprogs explicitly
On Sun, Jan 14, 2018 at 08:07:38PM +0100, Helmut Grohne wrote: > Package: live-build [...] > /usr/share/live/build/functions/losetup.sh contains mke2fs. According to file > it is a POSIX shell script, ASCII text executable [...] I can only find mke2fs mentioned in a comment: https://sources.debian.org/src/live-build/1:20171207/functions/losetup.sh/#L64 My conclusion is thus that this is a false positive and the bug report should simply be closed. Would be great to hear from maintainers about what they think of potential relationship between live-build and e2fsprogs. Regards, Andreas Henriksson
Bug#887285: virtinst should depend on e2fsprogs explicitly
On Sun, Jan 14, 2018 at 08:12:22PM +0100, Helmut Grohne wrote: > Package: virtinst [...] > /usr/share/virt-manager/virtinst/initrdinject.py contains debugfs. According > to file it is a Python script, ASCII text executable [...] initrdinject.py indeed has code to launch debugfs command inside a function called _rhel4_initrd_inject. The first thing this function does is try to determine if we're dealing with a RHEL 4 initrd and if not bail out (before any use of debugfs command). I assume this logic is functioning as expected and thus there's no reason to believe debugfs will ever get launched on Debian, but maybe that's an incorrect assumption since I have no knowledge on how to use or even what purpose the tool has. https://sources.debian.org/src/virt-manager/1:1.4.3-1/virtinst/initrdinject.py/#L33 My conclusion is that this bug report should likely just be closed without any changes. Would be great to hear from maintainers if my assumptions (and conclusion) makes sense here! Regards, Andreas Henriksson
Bug#887263: [Pkg-dkms-maint] Bug#887263: dkms should depend on e2fsprogs explicitly
Control: severity -1 minor Control: retitle -1 dkms should suggest e2fsprogs Hello Mario Limonciello, On Mon, Jan 22, 2018 at 03:34:09PM +, mario.limoncie...@dell.com wrote: > I would agree Suggests makes sense in this context. [...] > I'm not active in DKMS anymore (Someone else in Dell maintains it now), > but hope my comments are useful since I had some history from this. Thanks for your detailed feedback. Personally I find it very helpful just to get some feedback that suggests makes sense. I hope the details you provided can help current maintainers make the package even better. I'm adjusting the bug report to reflect that this should be considered a minor issue (unlike a missing dependency). Regards, Andreas Henriksson
Bug#887292: libsnapper4 should depend on e2fsprogs explicitly
On Sun, Jan 14, 2018 at 08:07:14PM +0100, Helmut Grohne wrote: > Package: libsnapper4 [...] > /usr/lib/x86_64-linux-gnu/libsnapper.so.4.1.0 contains chattr. According to > file it is a ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux) [...] The ext4 specific module indeed uses chattr, but not before it checks if the program is available and throws an exception if not. The only thing it does before that is the same check for 'chsnap' command, which isn't even available in Debian archive. Google told me "chsnap is only ever used if your root is ext4", so presumably libsnapper is commonly used with other filesystem types atleast in Debian. My conclusion is that either this package is completely fubar or there's likely no need for a dependency. (Possibly a suggests or so could still be useful though.) Would be great to hear from maintainers what's going on here... Regards, Andreas Henriksson
Bug#887294: gbrowse should depend on e2fsprogs explicitly
On Sun, Jan 14, 2018 at 08:05:01PM +0100, Helmut Grohne wrote:
> Package: gbrowse
[...]
> /usr/bin/gbrowse_grow_cloud_vol contains resize2fs. According to file it is a
> Perl script text executable
The same file also uses vgdisplay, but there's no package relationship
against lvm2 specified.
> /usr/share/perl5/Bio/Graphics/Browser2/DataSource.pm contains e2label.
> According to file it is a Perl5 module source, ASCII text
> /usr/share/perl5/Bio/Graphics/Browser2/Render.pm contains e2label. According
> to file it is a Perl5 module source, ASCII text
both above are false positives, type2label + feature2label.
> /usr/share/perl5/Bio/Graphics/Browser2/Render/Slave/AWS_Balancer.pm contains
> e2fsck and resize2fs. According to file it is a Perl5 module source, ASCII
> text
>From code:
$self->ssh('sudo e2fsck -f -p /dev/volumes/gbrowse') or die
"e2fsck failed";
$self->ssh('sudo resize2fs -p /dev/volumes/gbrowse') or die
"Couldn't resize2fs";
Looks like the commands are executed on a remote host over ssh so a local
dependency isn't what we want here.
> /usr/share/perl5/Bio/Graphics/Browser2/RenderPanels.pm contains e2label.
> According to file it is a Perl5 module source, ASCII text
> /usr/share/perl5/Bio/Graphics/Browser2/TrackDumper.pm contains e2label.
> According to file it is a Perl5 module source, ASCII text
> /usr/share/perl5/Legacy/Graphics/Browser.pm contains e2label. According to
> file it is a Perl5 module source, ASCII text
[...]
All three above are false positives, type2label + feature2label.
My conclusion is thus that this bug report can likely simply be
closed.
Would be great to get some input from maintainers on what's going
on in (the affected part of) gbrowse...
Regards,
Andreas Henriksson
Bug#887300: python-heat should depend on e2fsprogs explicitly
On Sun, Jan 14, 2018 at 08:09:36PM +0100, Helmut Grohne wrote: > Package: python-heat [...] > /usr/lib/python2.7/dist-packages/heat_integrationtests/scenario/templates/test_volumes_delete_snapshot.yaml > contains mkfs.ext4. According to file it is a ASCII text [...] The yaml file does indeed contain a shell script snippet which contains the mkfs.ext4 command. The same snippet also uses (non-essential) command curl, but there's no curl build-dependency specified which makes me assume this shell script snippet is not actually executed. My conclusion is that this bug report can likely just be closed. It seems like there's stuff in debian/rules that atleast tries to run the testsuite so tests should not be completely disable atleast. Would be great to hear from maintainers what's going on here Regards, Andreas Henriksson
Bug#887282: nilfs-tools should depend on e2fsprogs explicitly
Control: severity -1 minor Control: retitle -1 nilfs-tools should consider suggesting e2fsprogs (uses /sbin/badblocks) On Sun, Jan 14, 2018 at 08:08:09PM +0100, Helmut Grohne wrote: > Package: nilfs-tools [...] > /sbin/mkfs.nilfs2 contains badblocks. According to file it is a ELF 64-bit > LSB executable, x86-64, version 1 (SYSV) [...] Indeed /sbin/badblocks is used, but there's code to check if it's available and bail out of disk checking with a warning message if not. I'd say this warrants at most a 'Suggests: e2fsprogs' relationship. Leaving it up to maintainer to decide if this should simply be closed or if adding the suggests is useful. Regards, Andreas Henriksson
Bug#887226: cloud-init should depend on e2fsprogs explicitly
Control: severity -1 minor
Control: retitle -1 cloud-init should consider suggesting e2fsprogs,
btrfs-progs, xfsprogs, ...
On Sun, Jan 14, 2018 at 08:03:22PM +0100, Helmut Grohne wrote:
> Package: cloud-init
[...]
> /usr/lib/python3/dist-packages/cloudinit/config/cc_resizefs.py contains
> resize2fs. According to file it is a Python script, ASCII text executable
[...]
A code snippet from cc_resizefs.py:
>8-8<--->8-8<
def _resize_btrfs(mount_point, devpth):
return ('btrfs', 'filesystem', 'resize', 'max', mount_point)
def _resize_ext(mount_point, devpth):
return ('resize2fs', devpth)
def _resize_xfs(mount_point, devpth):
return ('xfs_growfs', devpth)
def _resize_ufs(mount_point, devpth):
return ('growfs', devpth)
# Do not use a dictionary as these commands should be able to be used
# for multiple filesystem types if possible, e.g. one command for
# ext2, ext3 and ext4.
RESIZE_FS_PREFIXES_CMDS = [
('btrfs', _resize_btrfs),
('ext', _resize_ext),
('xfs', _resize_xfs),
('ufs', _resize_ufs),
]
>8-8<--->8-8<
Given that cloud-init package doesn't specify a relationship to any
of the other filesystem specific packages shipping resizing tools
I'm going to assume there's no need for e2fsprogs relationship either.
It probably wouldn't hurt to add atleast a Suggests for all of them
though
Would be great to hear the maintainers view on this.
Regards,
Andreas Henriksson
Bug#887225: gparted should depend on e2fsprogs explicitly
Control: severity -1 minor Control: retitle -1 gparted should also suggest e2fsprogs On Sun, Jan 14, 2018 at 08:05:25PM +0100, Helmut Grohne wrote: > Package: gparted [...] > /usr/sbin/gpartedbin contains debugfs, dumpe2fs, e2fsck, e2image, e2label, > resize2fs and tune2fs. According to file it is a ELF 64-bit LSB shared > object, x86-64, version 1 (GNU/Linux) [...] I'm going to make a sweeping assumption here that e2fsprogs belongs among all the other filesystem specific stuff that gparted currently has specified as: Suggests: xfsprogs, reiserfsprogs, reiser4progs, jfsutils, ntfs-3g, dosfstools, mtools, yelp, kpartx, dmraid, dmsetup, gpart (I could ofcourse be wrong in that gparted somehow has a special relation to ext* filesystems, but from a very quick look at the code I couldn't find anything that suggested that.) Regards, Andreas Henriksson
Bug#887210: rkhunter should depend on e2fsprogs explicitly
Control: severity -1 minor On Sun, Jan 14, 2018 at 08:10:53PM +0100, Helmut Grohne wrote: > Package: rkhunter [...] > /usr/bin/rkhunter contains chattr and lsattr. According to file it is a POSIX > shell script, ASCII text executable, with very long lines, with escape > sequences > /var/lib/rkhunter/db/i18n/cn contains lsattr. According to file it is a UTF-8 > Unicode text [...] I've ignored /var/lib/rkhunter/db/i18n/* as false positives since they seem to simply be translations. Looking at rkhunter it seems chattr is a false positive match. There are a few false positive matches for lsattr as well, but one of them is interesting. lsattr is part of the list of commands stored in CMDLIST variable. Here's a code comment from rkhunter check_commands function about CMDLIST: # We check for some commands used in the tests. If the command # is found then a variable including the command name is set. # These commands are not 'required', so nothing happens if the # command is not found. The commands can be defined in the # configuration file, and a value of 'DISABLED' will cause a # command to not exist. A value of 'BUILTIN' may be used for # the 'stat' and 'readlink' commands, to indicate that the # supplied scripts should be used. We have to handle the 'stat' # command in a special way so that the perl module does not get # used if the command is to be disabled. You can indeed that the lsattr command is not strictly necessary by searching for LSATTR_CMD and seeing how it's only conditionally executed if available. Thus I'd say at most a Suggests or possibly Recommends is warrented, but not a Depends. Even just closing this bug report without a Suggests might be an option. I'll leave that up to the maintainer to decide. Would be great to hear from maintainer on this Regards, Andreas Henriksson
Bug#887263: dkms should depend on e2fsprogs explicitly
On Sun, Jan 14, 2018 at 08:03:50PM +0100, Helmut Grohne wrote: > Package: dkms [...] > /usr/sbin/dkms contains mke2fs. According to file it is a Bourne-Again shell > script, ASCII text executable, with very long lines [...] Indeed dkms uses both mke2fs and mkdosfs. There's no relation from dkms towards dosfstools specified in the dkms package either, which would otherwise be a sign of how important these commands are to dkms functionality. The commands are (only) used from a function called "make_driver_disk_floppy" which in turn is invoked (via a call chain) from "make_driver_disk" and that function checks distro which seems to be specified from commandline flag -d . (Note that there's no debian alternative! There is one for ubuntu though.) The command to invoke the code path seems to be something like 'dkms mkdriverdisk -d [...]'. Note that while today we can probably consider floppies to not be so common anymore, the default media type in dkms mkdriverdisk is floppy. I'm not sure how important this functionality is, but the entire thing seems to be pretty overlooked from a Debian perspective which leads me to assume a Suggests (rather than Recommends or Depends) might be suitable. I'm left with a few questions that it would be great to hear maintainers view on * Is the mkdriverdisk functionality useful at all these days? Maybe it should just be patched out (and possibly even removed upstream)? * If useful, shouldn't someone work on a debian distro code-path? * Shouldn't floppies be considered uncommon enough that the default should be changed to something else? All of these are off-topic in this particular bug report though and separate bug reports should probably be opened if there's a need to discuss any of that. Possibly upstream rather than in Debian. My conclusion here is that it's likely not the end of the world if we just closed this bug report. If a package relationship should be added using 'Suggests: dosfstools, e2fsprogs' would likely be the most suitable. Maintainers view on this would be nice to hear! Regards, Andreas Henriksson
Bug#887255: lvm2 should depend on e2fsprogs explicitly
On Sun, Jan 14, 2018 at 08:07:47PM +0100, Helmut Grohne wrote: > Package: lvm2 [...] > /sbin/fsadm contains resize2fs and tune2fs. According to file it is a > Bourne-Again shell script, ASCII text executable [...] The fsadm(.sh) script does indeed invoke both tune2fs and resize2fs under certain circumstances, so from a laymans view there should definitely be a dependency added. On the other hand maybe the fsadm script isn't that important to the rest of lvm and only offered as a convenience to the user. In that case it may possibly be argued that recommends would be ok to use instead of depends. Would be great to get some feedback from the maintainer(s)! Regards, Andreas Henriksson
Bug#887181: sosreport should depend on e2fsprogs explicitly
On Sun, Jan 14, 2018 at 08:11:31PM +0100, Helmut Grohne wrote: > Package: sosreport [...] > /usr/share/sosreport/sos/plugins/cman.py contains debugfs. According to file > it is a C++ source, ASCII text > /usr/share/sosreport/sos/plugins/dlm.py contains debugfs. According to file > it is a C++ source, ASCII text > /usr/share/sosreport/sos/plugins/filesys.py contains dumpe2fs. According to > file it is a C++ source, ASCII text > /usr/share/sosreport/sos/plugins/gfs2.py contains debugfs. According to file > it is a C++ source, ASCII text > /usr/share/sosreport/sos/plugins/kvm.py contains debugfs. According to file > it is a C++ source, ASCII text [...] All the debugfs matches seems to be false positives, but filesys.py is interesting. The following commands seems to be used (but I'm not sure exactly what the impact of them missing are, if only the information will be missing from report or complete failure): mount, df, findmnt, lsof, dumpe2fs It thus looks like the package might need to add the following dependencies: mount, lsof, e2fsprogs If command failure is ok, then a recommends might be more suitable. Would be great to hear something from the maintainer on this matter. Regards, Andreas Henriksson
Bug#887207: qemu-utils should depend on e2fsprogs explicitly
Control: tags -1 + patch
Hello,
On Sun, Jan 14, 2018 at 08:10:26PM +0100, Helmut Grohne wrote:
> Package: qemu-utils
[...]
> /usr/sbin/qemu-make-debian-root contains mke2fs. According to file it is a
> POSIX shell script, ASCII text executable
[...]
The qemu-make-debian-root script is not part of upstream but comes from
the debian/ packaging directory.
The script starts with checking for debootstrap existance and erroring
out with a helpful message if not found.
I would suggest extending the debootstrap check with also checking for
other commands used in the script and erroring out if they are missing
in a similar fashion. (eg. losetup, sfdisk, mke2fs, etc.)
If the previous suggestion is implemented, also having qemu-utils
Suggest mount, fdisk, e2fsprogs is likely a good idea.
This should then also fix #872098.
A patch implementing the previous suggestion has been attached for
your convenience. Please test and review it carefully.
Regards,
Andreas Henriksson
diff --git a/debian/changelog b/debian/changelog
index 9f4f14d..b62b701 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+qemu (1:2.11+dfsg-1.1) UNRELEASED; urgency=medium
+
+ * debian/qemu-make-debian-root: verify existance of losetup, mount,
+sfdisk and mke2fs commands and suggest their respective relevant
+package might not be installed if command not found.
+(Closes: #872098, #887207)
+ * Add fdisk, mount, e2fsprogs to what qemu-utils suggests.
+
+ -- Andreas Henriksson <andr...@fatal.se> Sat, 20 Jan 2018 02:27:47 +0100
+
qemu (1:2.11+dfsg-1) unstable; urgency=medium
[ Michael Tokarev ]
diff --git a/debian/control b/debian/control
index 5aff925..b8a1041 100644
--- a/debian/control
+++ b/debian/control
@@ -394,7 +394,7 @@ Package: qemu-utils
Architecture: amd64 arm arm64 armel armhf hppa i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel mips64 mips64el powerpc powerpcspe ppc64 ppc64el s390x sparc sparc64 x32
Multi-Arch: foreign
Depends: ${shlibs:Depends}, ${misc:Depends}
-Suggests: debootstrap, qemu-block-extra (= ${binary:Version}),
+Suggests: debootstrap, fdisk, mount, e2fsprogs, qemu-block-extra (= ${binary:Version}),
Description: QEMU utilities
QEMU is a fast processor emulator: currently the package supports
ARM, CRIS, i386, M68k (ColdFire), MicroBlaze, MIPS, PowerPC, SH4,
diff --git a/debian/control-in b/debian/control-in
index 8e0a60f..bcfae15 100644
--- a/debian/control-in
+++ b/debian/control-in
@@ -404,7 +404,7 @@ Package: qemu-utils
Architecture: amd64 arm arm64 armel armhf hppa i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel mips64 mips64el powerpc powerpcspe ppc64 ppc64el s390x sparc sparc64 x32
Multi-Arch: foreign
Depends: ${shlibs:Depends}, ${misc:Depends}
-Suggests: debootstrap, qemu-block-extra (= ${binary:Version}),
+Suggests: debootstrap, fdisk, mount, e2fsprogs, qemu-block-extra (= ${binary:Version}),
Description: QEMU utilities
QEMU is a fast processor emulator: currently the package supports
ARM, CRIS, i386, M68k (ColdFire), MicroBlaze, MIPS, PowerPC, SH4,
diff --git a/debian/qemu-make-debian-root b/debian/qemu-make-debian-root
index a22d1bc..947e93d 100755
--- a/debian/qemu-make-debian-root
+++ b/debian/qemu-make-debian-root
@@ -7,11 +7,22 @@
set -e
-which debootstrap >/dev/null || {
-echo "error: missing debootstrap package" >&2
-exit 1
+verify_command_installed() {
+CMD=$1
+PKG=$2
+which $CMD >/dev/null || {
+echo "error: $CMD not found in PATH, possibly missing $PKG package" >&2
+exit 1
+}
}
+verify_command_installed debootstrap debootstrap
+for CMD in losetup mount ; do
+verify_command_installed $CMD mount
+done
+verify_command_installed sfdisk mount
+verify_command_installed mke2fs e2fsprogs
+
KEEPFS=0
SPARSE=0
Bug#887197: ansible should depend on e2fsprogs explicitly
Hello,
On Sun, Jan 14, 2018 at 08:02:41PM +0100, Helmut Grohne wrote:
> Package: ansible
[...]
> /usr/lib/python2.7/dist-packages/ansible/module_utils/basic.py contains
> chattr and lsattr. According to file it is a Python script, ASCII text
> executable
Calls to chattr and lsattr are guarded by first checking for their
existance. (No strong dependency needed here.)
Examples:
attrcmd = self.get_bin_path('chattr')
if attrcmd:
attrcmd = self.get_bin_path('lsattr', False)
if attrcmd:
And the get_bin_path returns None if the command can not be found in
either PATH or any of /sbin, /usr/sbin, /usr/local/sbin.
> /usr/lib/python2.7/dist-packages/ansible/module_utils/facts/hardware/aix.py
> contains lsattr. According to file it is a C++ source, ASCII text
Occurances of lsattr are all hardcoded to /usr/sbin/lsattr (just like all
other command executions in this file). Dependency most likely needed.
(This could potentially be improved via upstream to use a similar method
to the previous basic.py to look up the path and check for existance if
avoiding a hard dependency on e2fsprogs and hardcoding the lsattr path
is desirable.)
> /usr/lib/python2.7/dist-packages/ansible/module_utils/facts/network/aix.py
> contains lsattr. According to file it is a C++ source, ASCII text
Execution of lsattr is guarded by first checking for its existance.
(No dependency needed based on this occurance.)
> /usr/lib/python2.7/dist-packages/ansible/modules/files/stat.py contains
> lsattr. According to file it is a Python script, ASCII text executable
False positive. The one lsattr occurance is in a documentation part.
> /usr/lib/python2.7/dist-packages/ansible/modules/system/filesystem.py
> contains mkfs.ext2, mkfs.ext3, mkfs.ext4, resize2fs and tune2fs. According to
> file it is a Python script, ASCII text executable
Commands are wrapped in module.get_bin_path with the required argument set
to True which returns a json error. While the code may not crash without
the commands, functionality will likely be lost. How severe the functionaly
loss is hard for me to tell, but I'll assume this warrants a dependency on
e2fsprogs.
> /usr/lib/python2.7/dist-packages/ansible/utils/module_docs_fragments/files.py
> contains chattr and lsattr. According to file it is a C++ source, ASCII text
[...]
False positive. Documentation.
In summary there are mainly two cases to consider here. Would be great
to hear from maintainer(s) what their thought is on how to best see
this through. Without further input I'd say a Depends on e2fsprogs
is likely the best solution.
Regards,
Andreas Henriksson
Bug#887176: resolvconf should depend on e2fsprogs explicitly
Hello, On Sun, Jan 14, 2018 at 08:10:44PM +0100, Helmut Grohne wrote: > Package: resolvconf [...] > /usr/share/resolvconf/dump-debug-info contains lsattr. According to file it > is a POSIX shell script, ASCII text executable This one uses lsattr, but guards the execution with checking if it exists first, so no strict dependency needed for this. Basing my assumption on the file name a Suggests would likely be more warranted than a Recommends. > DEBIAN/postinst contains chattr and lsattr. According to file it is a POSIX > shell script, ASCII text executable [...] The postinst maintainerscript does indeed use both chattr and lsattr. Both of them are guarded with the debconf variable resolvconf/linkify-resolvconf having to be TRUE, which is the default. A dependency is thus currently needed here! An alternative approach if there's a reason to consider avoiding adding a strict dependency would be to refactor the debian/config to check for chattr/lsattr existance and if they're not available force the debconf variable resolvconf/linkify-resolvconf to false (likely together with a debconf prompt stating that). I'm not sure if the extra complexity is worth it and it would be great if maintainer(s) could comment on this. My conclusion is that a e2fsprogs dependency is likely the best solution. Regards, Andreas Henriksson
