Re: Steps towards a patch to document disabling a daemon upon installation
Hello Sean Whitton, Thanks for your work on this. Hopefully you'll find something in my comments inlined below of any use... On Sat, Sep 09, 2017 at 01:40:18PM -0700, Sean Whitton wrote: > Hello, > > This is what I have so far; it is certainly inadequate. CCing -devel > for help answering my technical questions about this patch. > > > @@ -537,6 +537,21 @@ and in your ``postrm`` > > update-rc.d package remove > > fi > > > > +The default behaviour is to enable autostarting your package's daemon. > > +If the daemon should not be autostarted unless the local administrator > > +has explicitly requested this, use instead add to your ``postinst`` > > +script > > + > > +:: > > + > > +update-rc.d package defaults > > +update-rc.d package disable I can't help myself but repeat that I'd prefer seeing more passive wording eg. instead of "instead add to your postinst" use something like "the postinst should contain" + a footnote about this normally being added by dh_... Manually written maintainer scripts should be avoided and I've seen people being "fooled" by taking policy literally before. (Maybe this deserves a section of its own?) > > + > > +An older practice, which should not be used, was to include a line > > +like ``DISABLED=yes`` in the package's ``/etc/default`` file. The > > +package's init script would not start the service until the local > > +system administrator changed this to ``DISABLED=no``, or similar. > > + > > Note that if your package changes runlevels or priority, you may have to > > remove and recreate the links, since otherwise the old links may > > persist. Refer to the documentation of ``update-rc.d``. > > 1. Is the 'should not' for the /etc/default practice too strong? Not in my opinion, no. >I don't know an efficient way to find out how many packages this >would make buggy. But given that we have very strong reasons >against the old practice, we might want to use a 'should not' >regardless. Any maintainer being hit by policy extremists have two options: 1. Take the opportunity to fix the package to follow best pracises. 2. Postpone by saying "should not" is not "must not" (and lower severity), plus "patches welcome" ofcourse. I think that's good enough. > > 2. Do we need to include any text saying *why* the /etc/default practice >is a bad idea? I couldn't come up with a succinct way to state it. >In general, I think we can err on the side of not including the text, >since we have policy bugs that document the reasons. I don't think elaborating on all the ways something can be done incorrectly is nessessary. Should not be too hard for anyone interested in the reason to find out atleast one reason either by thinking it through by themselves or by googling for past discussions. If anything I'd rather see helpful suggestions (in footnotes?) on how a proper cleanup should be done. (Convert admin changes on upgrades, use debian/*.maintscript to rm_conffile) > > 3. The maintscript snippet I have added is not right because it will >disable the daemon every time the package is updated. Unfortunately, >the postinst doesn't know whether this is a new installation, or an >upgrade. > >An alternative is to require the package maintainer to set the >correct LSB headers and systemd unit file configuration values such >that the daemon is not autostarted (in the former case, setting the >daemon not to be started at any runlevel). But I think this would >prevent the local system administrator from enabling the service with >a simple `update-rc.d package enable`, which is the whole point of >all this. > >I looked at dh_installinit(8) and update-rc.d(8) and I couldn't get >them to generate a postinst that does what I want. It seems you're >expected to use all three of these: > >dh_systemd_enable --no-enable >dh_systemd_start --no-start >dh_installinit --no-start > >but then after a reboot, a sysvinit system will start the daemon, >AFAICT. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709384 Regards, Andreas Henriksson
Re: IMPORTANT: Do live Debian images have a future?
Hi! Steve McIntyre: > While the bugs are annoying, what worries me more is that they were > only spotted in release builds. There had been testing versions of > live images available for multiple weeks beforehand, presumably with > the same bugs included. (Almost) none of them reported. This shows > that we don't have enough people using these live images and/or caring > about filing bugs. I have a slightly different PoV on the situation here, that leads me to different conclusions. I had a good look at the list of bugs you pointed to, and frankly I'm not surprised at all that these bugs were not reported earlier: very few of them affect in a user-visible manner the use case I *guess* is the most common one, i.e. booting a desktop Debian Live system to give the next version a try without installing to disk. For example, we can't realistically expect Debian + GNOME users to even notice things like "Incorrect Volume ID used for all live images" or "not configuring UTF-8 console correctly". I acknowledge that those are bugs, but if nobody reported them, it's perhaps because in practice, nobody was affected negatively enough to bother reporting, rather than because not enough people even tested it ⇒ the perceivable quality of our Live images, from a user's PoV, is perhaps not *that* bad :) FTR we did test the GNOME live ISO a lot during the "more than a Debian BSP" event in Paris back in May, and the only one we noticed from your list was #865015… that we erroneously attributed to faulty hardware… sorry! We also reported a number of other bugs against the debian-live package, and they have not been acted upon so far. So from where I stand, the lack of developer time available to resolve issues *that users do notice* looks like a more severe problem than the lack of testing in itself. The good news is that despite these bugs, the live images we tested worked pretty well :) > We have a similar lack of involvement in terms of the content of the > live images. […] Validation by the various desktop teams would be > useful here. Fully agreed. IMO "building & distributing a Debian Live image for desktop X" should be put explicitly as something that the team for desktop X can opt-in for if, and only if, they feel comfortable committing to validate the content somewhat. And then, whenever you feel they don't meet the expectations you've set, then you can drop the problematic ones so the problem is visible. Is there technical difficulty involved in adding to / removing from the list of desktops for which we build Live images? I hope not, but who knows :) > The current situation is *not* good enough. [...] It looks like you feel trapped in a role you did not choose. I feel sorry for this and I want to express support for your attempt to escape. > If our live images are going to be good enough to meet the standards > that Debian users deserve and expect, we need *consistent*, > *sustained* involvement from a lot more people. ACK > Please tell me if you're going to help. (What follows was decided only a dozen days ago and I was waiting for this decision before I replied here, hence the delay.) By the end of the year I'll be able to tell whether I have a new, strong incentive to put efforts into automatic testing of Debian Live GNOME images: at Tails we will decide later this year whether we try basing our product on quarterly snapshots of Debian testing (to start with: at least until the end of the Buster cycle). If we do so, then I bet that we (Tails) will want to invest into identifying bugs ASAP i.e. in Debian testing/sid and more specifically in Debian Live GNOME images built from Debian testing/sid. I recognize this can replace neither involvement from desktop teams, nor exploratory testing by humans. > If we don't see a radical improvement soon, I'll > simply disable building live images altogether to remove the false > promises they're making. This sounds entirely reasonable. I'm all for our Debian heroes & martyrs going on strike, and for not hiding problems! Take care, and thanks for making this move :) Cheers, -- intrigeri
Bug#875290: ITP: ruby-erubi --small ERB implementation
Package: wnpp Severity: wishlist Owner: Kartik Kulkarni X-Debbugs-CC: debian-devel@lists.debian.org * Package name: ruby-erubi Version :1.6.1 Upstream Author : Jeremy Evans kuwata-lab.com * URL : https://github.com/jeremyevans/erubi * License : Expat Programming Lang: Ruby Description: Small ERB Implementation Erubi is a ERB template engine for ruby. It is a simplified fork of Erubis. . ERB stands for Embedded Ruby. It is a dependency of gitlab 9 I am not a debian member and would like to maintain this package for a long term and would like to join the Ruby maintainers group, Praveen had agreed to sponsor this package.
Re: suil - current packaging query
Hi! On Sun, 2017-09-10 at 07:12:08 +0100, Phil Wyett wrote: > I found audacity now uses suil. > http://git.drobilla.net/cgit.cgi/suil.git/tree/PACKAGING > > The bottom section of the doc: > > *** IMPORTANT GUIDELINES FOR PACKAGING SUIL *** > > The purpose of Suil is to abstract plugin UI toolkits away from host code. To > achieve this, Suil performs its magic by dynamically loading modules for each > toolkit. The main Suil library does NOT depend on any toolkit libraries, and > thus neither should your package. Please package the individual modules > (e.g. libsuil_gtk2_in_qt4.so) as separate packages, which themselves depend on > the involved toolkits. These packages should also be versioned as described > above to support parallel installation. > > Please do not make the main Suil package depend on any toolkit package, this > defeats the purpose of Suil and will severely irritate those who for whatever > reason do not want a particular toolkit dependency. The main Suil package may > have a weak dependency (e.g. "recommends") on the individual wrapper modules, > and it's fine if these are installed by default, but it must be possible to > install Suil without installing them if the user explicitly wishes to do so. > > // End > Is it just me or should this package be broken down into a core and subset > module packages? IMO yes. Although it seems this might require some tooling support and a small transition. > Any thoughts and how suil should be better packaged welcome. AFAIUI, the Suil library provides an interface so that an LV2 host can load on-demand at run-time the UI required by the LV2 plugin w/o needing the host to directly link to those UI libraries itself. So I think the ideal situation would be: * Keep a libsuil-N-M shared library package with just the shared lib. * Move the suil UI plugins into their own packages grouped by UI, something like (assuming that we just drop the Qt4 right away): - libsuil-(mod|plugin)-gtk2-(in-)qt5 (w/ libsuil_gtk2_in_qt5.so) - libsuil-(mod|plugin)-x11-(in-)gtk2 (w/ libsuil_x11_in_gtk2.so) - libsuil-(mod|plugin)-x11-(in-)qt5 (w/ libsuil_x11_in_qt5.so) * Add a new packaging helper (dh_suil-plugin?) that would analyze the plugin .ttl files to check for the UI used and emit a dependency on the LV2 plugin package against the required libsuil-(mod|plugin)-UI packages. The transition would imply: * Split the suil packages, and make libsuil-N-M depend on all UI plugins to not break any LV2 plugin. * Write the dh-suil-plugin tooling. * Modify all LV2 plugins to depend on the required Suil UI plugins. * Then drop the UI plugin dependencies from libsuil-N-M, either after one entire release cycle, or after adding appropriate Breaks against all LV2 plugins using UI plugins. > Bug report? Probably yes. :) Thanks, Guillem
Re: Steps towards a patch to document disabling a daemon upon installation
On Sep 09, Sean Whitton wrote: > 1. Is the 'should not' for the /etc/default practice too strong? I No, because it cannot be supported in a sane way by systemd units. It should even be "must not". -- ciao, Marco signature.asc Description: PGP signature
Re: Let's enable AppArmor by default (why not?)
Hi John, very interesting read! On Sat, Sep 09, 2017 at 02:07:32PM -0700, John Johansen wrote: > On 09/09/2017 12:49 PM, intrigeri wrote: > > Hi John et al, > > > > John Johansen: > >> On 08/09/2017 02:31 PM, intrigeri wrote: > >>> Moritz Mühlenhoff: > Christian Seiler schrieb: > > Another thing to consider: if a profile is too restrictive, but the > > part that is too restrictive isn't in the upstream kernel yet, then > > things could break if you upgrade the kernel to a newer version from > > e.g. backports later on. How would you deal with that kind of > > breakage during the lifetime of a stable release? > >>> > Agreed, that was pretty much my concern. > >>> > >>> Thank you so much for highlighting problems I had missed! :) > >>> > >>> A simple, but not entirely satisfying answer is: > >>> > >>> 1. Gather info about how real this problem has been in practice for > >>>Ubuntu: they frequently update their kernel for various already > >>>released distros with the latest AppArmor bits. I think they > >>>occasionally have to update other packages accordingly to adjust > >>>AppArmor policy. I don't know how often this happens. I'll ask them > >>>to compile a list of such stable updates. > > > >> [...] > >> The question specifically asks about, an updated kernel with a policy > >> that was developed under a different feature set, suddenly breaking > >> when a new kernel is run on an older system. > > > > Right. > > > > Below you elaborate about ABI compatibility between the kernel, > > userspace and policy. Thanks, I've learned a lot! > > > > But even more specifically, the question was about policy updates > > mandated to avoid breaking *confined applications* when upgrading to > > a kernel that mediates more interfaces than the one in Debian stable. > > > > haha, I had a broader answer dealing with some of this and upon review > had decided the question was about a newer kernel on an older release, > and it would be best to have concise answers around that :) > > > Christian Seiler put it clearly (quoted above) but here's a more > > practical example: say 1. D-Bus mediation lands in Linux > > 4.15 (totally made up, but this would be nice!); 2. I run Debian > > Stretch; 3. I have to run Linux 4.15+ from stretch-backports (e.g. > > on a shiny laptop that needs recent drivers). Then any AppArmor > > profile shipped in Debian Stretch that was developed without D-Bus > > mediation in mind can potentially start breaking the application > > it confines. > > > This is true, hence the suggestion to pin the feature set by > setting the features file in parser.conf This would prevent policy > from enforcing the dbus feature, and prevent the application > from breaking. > > I will admit this is not ideal because it applies to all policy loaded > in the namespace (a container could have its own parser and flags) > unless policy is manually loaded with a flag to override it. Which > prevents policy that has been developed with the new feature from > taking advantage of it in this scenario. > > There is some work to expose the feature set to policy which will let > policy conditionally choose which features it supports but I can't > promise when that work will land. > > > So our questions to Ubuntu & other distros are: > > How have you been dealing with such problems in the past few years? > > How often did you have to update packages in a stable release in > > order to fix them? > > > > Now, simply enabling AppArmor by default during the Buster development > > cycle will give us some of the answers: given many AppArmor features > > will land in Linux in the next months/years, we *will* notice if our > > policy is outdated :) > > > > So there are four separate components (kernel, userspace, policy, > application) to discuss here and different potential problems, > depending on the combination. > > - kernel: If the kernel is backported and the feature set is pinned > there is a low likely hood of problems. As I addressed previously > there is the potential for a kernel to make changes beyond > apparmor's control that change how/what permission requests reach > apparmor and this can cause problems. Thankfully in practice this > has not happened often. > > - apparmor userspace: Baring bugs, new userspaces should just work > with old kernels. Even if the feature set is not pinned, the > userspace will use the old kernel's feature set, so it is equivalent > to pinning. > > - applications: When newer versions of applications are backported > they can break under old policy because they provide new features > that old policy wasn't designed for. Policy must be tested and > updated as part of an application backport/SRU. This (and somewhat related the next point) is the reason why policy should be shipped by the application (that is the Debian package containing the application), not in an apparmor-profiles package. This makes sure th
Bug#875378: ITP: node-style-loader -- style loader module for webpack
Package: wnpp Severity: wishlist Owner: Daniel Ring X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-style-loader Version : 0.17.0 Upstream Author : Tobias Koppers @sokra * URL : https://github.com/webpack/style-loader * License : Expat Programming Lang: JavaScript Description : style loader module for webpack This library is a style loader module for webpack. This library is a dependency for webpack. Webpack takes code targeted at node.js and adapts it to run in the browser. Node.js comes with an API of its own that is not available in browsers. Webpack exposes this code to programs that are unaware they are running in a browser. Node.js is an event-based server-side JavaScript engine.
