Re: OpenLiteSpeed Build Script Violating Debian Upstream Guide
On Sat, 07 Mar 2020 at 16:54:04 -0700, Nicholas D Steeves wrote: > 2) or define > overrides in rules to ignore the upstream-provided build.sh and > configure scripts (CMake + accurate build-deps in control should be > enough to build the package) Using "dh $@ --buildsystem=cmake" (instead of "dh $@", which guesses which build system to use) might well be enough... > I'm assuming there aren't custom network-dependent CMake targets and > that the Policy violating stuff is limited to build.sh and configure. ... if this assumption is true. smcv
Bug#953356: ITP: esup-el -- Emacs StartUp Profiler
Package: wnpp Owner: Lev Lamberov Severity: wishlist * Package name: esup-el Version : 0.7.1 Upstream Author : Joe Schafer * URL or Web page : https://github.com/jschaf/esup * License : GPL-3+ Programming Lang: Emacs Lisp Description : Emacs StartUp Profiler This package profiles your Emacs startup time by examining all top-level S-expressions (sexps). It starts a new Emacs process from Emacs to profile each sexp. After the profiled Emacs is complete, it will exit and your Emacs will display the results. It will step into `require' and `load' forms at the top level of a file, but not if they're enclosed in any other statement.
Re: not starting a daemon upon installation
On Sat, 7 Mar 2020 23:02:23 +0100, Marco d'Itri wrote: >There is: > ># systemctl mask $DAEMON.service ># apt install $DAEMON > >That's it. If the package fails to install then file a bug. For that you need to know how the $DAEMON is called. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: not starting a daemon upon installation
On Sat, 7 Mar 2020 21:30:33 +0100, Tomas Pospisek >When I duckduckgo "dpkg do not start service on install" first hit is >[1] which contains /absurdly involved/ suggestions to achieve "not >starting a daemon upon installation". > >[1] >https://askubuntu.com/questions/74061/install-packages-without-starting-background-processes-and-services# This is indeed bordering between incredibly funny and disturbing. Alas, it's a golden example for the quality of answers one gets in the Ubuntu universe. -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: bootstrap.min.js in pydoctor
On Thu, Mar 5, 2020 at 3:52 AM Jonas Smedegaard wrote: > > Quoting Jonathan Carter (2020-03-05 10:44:50) > > On 2020/03/05 00:47, Sam Hartman wrote: > I agree for the _binary_ packages but not for the _source_ package. > > The changelog entry which Anthony referenced¹ says this: > > > * Add missing embedded epydoc and Bootstrap copyright info as well as > > non-minified source for bootstrap.min.css (Bootstrap v3.3.4) for > > DFSG compliance. > [...] > > * Symlink to bootstrap.min.css from libjs-bootstrap instead of > > shipping pydoctor included bootstrap.min.css v3.3.4 from 2015 > > As I understand the above, what was corrected for DFSG compliance was a > verification that the code included with the _source_ package was a > minification of css released by the Bootstrap3 project. > > I think that is a misunderstanding: Commonly this is indeed one way to > ensure DFSG compliance, but in this case - as Sam pointed out - it is > not enough. > > Source package must include the _source_ for the minified css, which in > this case is _not_ non-minified css but less code. Good point! After reading your message, I went ahead and included the less source code from Bootstrap 3.3.4 and made a new upload of pydoctor, see: * https://salsa.debian.org/python-team/applications/pydoctor/-/commit/f1c8209623b3b18e1d2019abcd2b1be1b04ab5d9 * https://tracker.debian.org/news/1107020/accepted-pydoctor-19110git2020030347424e7-1-source-into-unstable/ Cheers, Anthony
Re: Re: Re: OpenLiteSpeed Build Script Violating Debian Upstream Guide
On 2020-03-07 15:47 +0700, Bagas Sanjaya wrote: > > Packages must be self-contained, using only their contents and the Debian > > repo during the build process. There are multiple technical and > > non-technical reasons for this requirement, including knowing that the > > package is DFSG-compliant and being able to always rebuild the package. > But I found that `configure` script shipped with the OLS sources also invoke > `git-clone` > > BoringSSL instead of relying on yet-to-be-packaged Debian package, though So you need to package boringSSL before uploading this package. Including this local patch assuming that it is necessary - and in the process try to get that patch upstreamed in which case you will be able to drop it. Separately packaging build-dependencies is good policy, although it's not an absolute requirement (unlike the network download). You could ship a copy of the patched boringSSL as part of the openlightspeed source. But check how many other debian packages actually use boringSSL. There may be several packages in the same boat. (e.g when I packaged something that had an embedded copy of libsquish it turned out that 6 other packages were also shipping an embedded or patched embedded version, and it was fairly straightforward (with a bit of help from upstream) to incorporate all the various patches into one libsquish which then all those packages could just depend on. This is the right way to do things, but it does of course take more time and work then just stuffing yet another embedded 3rd party library into the source. Ideally upstreams would be doing this work, but many leave it to distros to tidy up their mess (and incorporate their laziness into build systems which just adds more bodging to undo). Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: not starting a daemon upon installation
On Sat, 2020-03-07 at 21:30 +0100, Tomas Pospisek wrote: > The problem is that installing the package will automatically start > the > daemon cluster in a "default" configuration. > > That's a problem for me because etcd differentiates between starting > the > cluster for the first time and starting it subsequentially. The first > time is special as it generates some internal state. > > So I would like to control whether etcd - or for the matter any > service > - is started upon package installation. > > I imagine that this would be quite a standard requirement for > devops/configuration tools aka "please do not run and configure the > service for me because I want to do it precisely **this way**" (which > is > kinda the point of configration automation). > > When I duckduckgo "dpkg do not start service on install" first hit is > [1] which contains /absurdly involved/ suggestions to achieve "not > starting a daemon upon installation". > > It /seems/ that the "official" way to achieve "not starting a daemon > upon installation" is to use `dpkg-divert` to overwrite `policy-rc.d` > with a script that exits with 101. > > This to me seems again like a awkward, byzantine and brittle way to > achieve that goal. Also, the only canonical documentation of policy- > rc.d > seems to be > /usr/share/doc/init-system-helpers/README.policy-rc.d.gz, which is > quite > cryptic, contains no examples and contains "rc.d" in its name in a > world > where systemd is the default, which makes me doubt whether all > packages > using systemd will respect policy-rc.d... > > So I'm wondering: > > * is this really the official (twisted ?8-o) way to solve the problem > of > not starting a daemon automatically upon installation? > * why was such an involved method chosen, instead of say setting an > environment variable DPKG_DONT_START_DAEMON or such? > > [1] > https://askubuntu.com/questions/74061/install-packages-without-starting-background-processes-and-services# i can't comment on what might be considered an "official" solution. fyi, preventing start/stop of _all_ services on package installation is a requirement of Debian's live-build, which if you're not familiar with it is a tool to build a Debian live-cd. Building a live environment is typically done in a chroot and it involves installing many packages which should not impact the host in terms of starting/stopping services. how live-build achieves this is essentially the same as happens to be discussed in the linked page for Debian's debootstrap package (the tool for building the base filesystem). that is to use dpkg-divert to temporarily replace the /sbin/start-stop- daemon binary with something that essentially just exits with success (i.e. 0). This could be an empty shell script (or one that prints a warning about the diversion being in place as in the linked discussion) or a symlink to /bin/true. enabling diversion: ``` dpkg-divert --add --rename /sbin/start-stop-daemon ln -fs /bin/true /sbin/start-stop-daemon ``` removing diversion: ``` rm -f /sbin/start-stop-daemon dpkg-divert --remove --rename /sbin/start-stop-daemon ``` someone else has already offered an alternate solution applicable to individual packages. if the problem you are experiencing with this particular package you reference is common, then perhaps a bug should be filed or discussion take place regarding changing it such that it not try to start its service upon installation.
Re: apt 2.0 release notes
On 3/7/20 9:41 PM, Julian Andres Klode wrote: > # APT 2.0 > > After brewing in experimental for a while, and getting a first outing in > the Ubuntu 19.10 release; both as 1.9, APT 2.0 is now landing in unstable. > 1.10 would be a boring, weird number, eh? > > Compared to the 1.8 series, the APT 2.0 series features several new features, > as well as improvements in performance, hardening. A lot of code has been > removed as well, reducing the size of the library. $ apt show >/dev/null | cat WARNING: apt does not have a stable CLI interface. Use with caution in scripts. Is there a roadmap when the CLI interface will become stable?
Re: not starting a daemon upon installation
On Sun, 08 Mar 2020 14:58:01 +, jnq...@gmail.com wrote: >fyi, preventing start/stop of _all_ services on package installation is >a requirement of Debian's live-build, which if you're not familiar with >it is a tool to build a Debian live-cd. Building a live environment is >typically done in a chroot and it involves installing many packages >which should not impact the host in terms of starting/stopping >services. > >how live-build achieves this is essentially the same as happens to be >discussed in the linked page for Debian's debootstrap package (the tool >for building the base filesystem). > >that is to use dpkg-divert to temporarily replace the /sbin/start-stop- >daemon binary with something that essentially just exits with success >(i.e. 0). debootstrap's files don't contain the string "divert". They do, however, dump "exit 101" to $TARGET/usr/sbin/poliy-rc.d. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: apt 2.0 release notes
Quoting Matthias Klose (2020-03-08 18:40:34) > On 3/7/20 9:41 PM, Julian Andres Klode wrote: > > # APT 2.0 > > > > After brewing in experimental for a while, and getting a first outing in > > the Ubuntu 19.10 release; both as 1.9, APT 2.0 is now landing in unstable. > > 1.10 would be a boring, weird number, eh? > > > > Compared to the 1.8 series, the APT 2.0 series features several new > > features, > > as well as improvements in performance, hardening. A lot of code has been > > removed as well, reducing the size of the library. > > $ apt show >/dev/null | cat > > WARNING: apt does not have a stable CLI interface. Use with caution in > scripts. > > Is there a roadmap when the CLI interface will become stable? I would not expect apt to ever get a stable interface for scripting. "man apt" says this in first paragraph of section DESCRIPTION: > apt provides a high-level commandline interface for the package > management system. It is intended as an end user interface and enables > some options better suited for interactive usage by default compared > to more specialized APT tools like apt-get(8) and apt-cache(8). I.e. for scripting, use apt-get instead. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: apt 2.0 release notes
On Sun, Mar 08, 2020 at 07:10:49PM +0100, Jonas Smedegaard wrote: > Quoting Matthias Klose (2020-03-08 18:40:34) > > $ apt show >/dev/null | cat > > > > WARNING: apt does not have a stable CLI interface. Use with caution in > > scripts. > > > > Is there a roadmap when the CLI interface will become stable? > > I would not expect apt to ever get a stable interface for scripting. > I.e. for scripting, use apt-get instead. Or in this case, apt-cache. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good. ⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi ⠈⠳⣄
Packaging new library very similar to another library
Hello! I maintain an image compression library https://github.com/GrokImageCompression/grok which is very similar to an existing package in debian: https://packages.debian.org/search?keywords=openjpeg I would like to package my library and add it to debian - can I re-use the packaging from OpenJPEG to do that ? Thank you! Aaron Boxer
Re: Packaging new library very similar to another library
Correction: this is the current package for openjpeg: https://tracker.debian.org/pkg/openjpeg2 On Sun, Mar 8, 2020 at 2:30 PM Aaron Boxer wrote: > Hello! > I maintain an image compression library > > https://github.com/GrokImageCompression/grok > > which is very similar to an existing package in debian: > > https://packages.debian.org/search?keywords=openjpeg > > I would like to package my library and add it to debian - can I re-use the > packaging from OpenJPEG to do that ? > > Thank you! > Aaron Boxer >
Re: apt 2.0 release notes
On Sun, Mar 08, 2020 at 07:10:49PM +0100, Jonas Smedegaard wrote: > Quoting Matthias Klose (2020-03-08 18:40:34) > > On 3/7/20 9:41 PM, Julian Andres Klode wrote: > > > # APT 2.0 > > > > > > After brewing in experimental for a while, and getting a first outing in > > > the Ubuntu 19.10 release; both as 1.9, APT 2.0 is now landing in unstable. > > > 1.10 would be a boring, weird number, eh? > > > > > > Compared to the 1.8 series, the APT 2.0 series features several new > > > features, > > > as well as improvements in performance, hardening. A lot of code has been > > > removed as well, reducing the size of the library. > > > > $ apt show >/dev/null | cat > > > > WARNING: apt does not have a stable CLI interface. Use with caution in > > scripts. > > > > Is there a roadmap when the CLI interface will become stable? > > I would not expect apt to ever get a stable interface for scripting. > > "man apt" says this in first paragraph of section DESCRIPTION: > > > apt provides a high-level commandline interface for the package > > management system. It is intended as an end user interface and enables > > some options better suited for interactive usage by default compared > > to more specialized APT tools like apt-get(8) and apt-cache(8). > > I.e. for scripting, use apt-get instead. We need to have an option that allows us to move forward with changes while also giving people the ability to write scripts that keep working. This has two dimensions: - Changes in output. It's reasonably easy to add an extensible output format and an option to switch to that for machine readable output - Changes in behavior. The only thing we can really do here is to version our behavior, and deprecate old behavior, and eventually remove it, while tracking a current and a future version, as debhelper does. It is questionable if we need both, or if we should just have the second one. Arguably, for most commands, you might want to track default behavior but still have a stable output format you can parse, and --machine-readable sounds nicer than --compat 1. I guess we could add a --compat switch now, make it do nothing, and remove the warning. Then when we add new behavior we can mark it for new versions only. Eventually I want to end up at a point where apt-* are symlinks to apt. We did not make it in this cycle (2.0), maybe we'll make it for bullseye (2.2). -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en signature.asc Description: PGP signature
Re: Packaging new library very similar to another library
On Sunday, March 8, 2020 2:32:54 PM EDT Aaron Boxer wrote: > Correction: this is the current package for openjpeg: > > https://tracker.debian.org/pkg/openjpeg2 > > On Sun, Mar 8, 2020 at 2:30 PM Aaron Boxer wrote: > > Hello! > > I maintain an image compression library > > > > https://github.com/GrokImageCompression/grok > > > > which is very similar to an existing package in debian: > > > > https://packages.debian.org/search?keywords=openjpeg > > > > I would like to package my library and add it to debian - can I re-use the > > packaging from OpenJPEG to do that ? > > > > Thank you! > > Aaron Boxer According to the packages debian/copyright file [1] you can as long as you follow the terms of the BSD 2 clause license (there is a copy of the license there too). Scott K [1] https://tracker.debian.org/media/packages/o/openjpeg2/copyright-2.3.1-1 signature.asc Description: This is a digitally signed message part.
Re: Packaging new library very similar to another library
On Sun, Mar 08, 2020 at 02:30:06PM -0400, Aaron Boxer wrote: > Hello! > I maintain an image compression library > > https://github.com/GrokImageCompression/grok > > which is very similar to an existing package in debian: > > https://packages.debian.org/search?keywords=openjpeg > > I would like to package my library and add it to debian - can I re-use the > packaging from OpenJPEG to do that ? Yes, though you should mention the copyright for debian/* in your debian/copyright. -- WBR, wRAR signature.asc Description: PGP signature
Re: apt 2.0 release notes
Hi, 在 2020-03-07六的 21:41 +0100，Julian Andres Klode写道： > # APT 2.0 > ### Incompatibilities > > * The apt(8) command no longer accepts regular expressions or wildcards as > package arguments, use patterns (see New Features). A little comment on this: I am okay with apt(8) no longer accepting regex or wildcards (which is still unfortunately a feature that I use every day) since the CLI interface volatility is well announced. I also understand the reason behind this move. However, I saw that there's plan to let apt-* stop accepting them as well after Bullseye release, according to the NEWS file (v1.9.6 NEWS). Please avoid this, or at least implement in a backward-compatible way (e.g., letting the user explicitly specify that they are using regex, apt-patterns or string with wildcard in the input via cmdline options; the default format is considered to be the fallback format/behavior). I saw countless scripts using this feature and the outcome of feature removal would be catastrophic. -- Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Re: apt 2.0 release notes
On Sun, Mar 08, 2020 at 02:40:56PM -0400, Boyuan Yang wrote: > Hi, > > 在 2020-03-07六的 21:41 +0100，Julian Andres Klode写道： > > # APT 2.0 > > ### Incompatibilities > > > > * The apt(8) command no longer accepts regular expressions or wildcards as > > package arguments, use patterns (see New Features). > > A little comment on this: I am okay with apt(8) no longer accepting regex or > wildcards (which is still unfortunately a feature that I use every day) since > the CLI interface volatility is well announced. I also understand the reason > behind this move. > > However, I saw that there's plan to let apt-* stop accepting them as well > after Bullseye release, according to the NEWS file (v1.9.6 NEWS). Please avoid > this, or at least implement in a backward-compatible way (e.g., letting the > user explicitly specify that they are using regex, apt-patterns or string with > wildcard in the input via cmdline options; the default format is considered to > be the fallback format/behavior). I saw countless scripts using this feature > and the outcome of feature removal would be catastrophic. This will be properly deprecated: * Soft deprecation: Until May 2020 (Ubuntu 20.04) apt-* behaves as before * Deprecation period: May 2020 - April 2022 (bullseye, and Ubuntu 22.04) apt-* will still accept regex/wildcard, but complain with a warning. * Removal: May 2022, post Ubuntu 22.04 release (and well past bullseye hopefully) apt-* will stop accepting wildcard. The deprecation period may be moved forward and shortened by approx one year: * Deprecation period: March 2020 - release of bullseye * Removal: after release of bullseye but only if I find time and get approval to add such warnings to Ubuntu 20.04, given that this is past feature freeze. But I don't think I'm very much interested in that. The removal is absolutely necessary, given the breakage that can happen when a package with a + in the name disappears from the repo. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en signature.asc Description: PGP signature
Re: not starting a daemon upon installation
On Sun, 2020-03-08 at 18:50 +0100, Marc Haber wrote: > On Sun, 08 Mar 2020 14:58:01 +, jnq...@gmail.com wrote: > > how live-build achieves this is essentially the same as happens to > > be > > discussed in the linked page for Debian's debootstrap package (the > > tool > > for building the base filesystem). > > > > that is to use dpkg-divert to temporarily replace the /sbin/start- > > stop- > > daemon binary with something that essentially just exits with > > success > > (i.e. 0). > > debootstrap's files don't contain the string "divert". They do, > however, dump "exit 101" to $TARGET/usr/sbin/poliy-rc.d. I had not looked at debootstrap's approach until just now. their's is indeed partially to use the policy-rc.d solution as you say, but also to do similar to the dpkg-divert solution only without actually using dpkg-divert, they just move the original file. extracting from debootstrap's scripts/debian-common: ``` echo \ "#!/bin/sh exit 101" > "$TARGET/usr/sbin/policy-rc.d" chmod 755 "$TARGET/usr/sbin/policy-rc.d" mv "$TARGET/sbin/start-stop-daemon" "$TARGET/sbin/start-stop- daemon.REAL" echo \ "#!/bin/sh echo echo \"Warning: Fake start-stop-daemon called, doing nothing\"" > "$TARGET/sbin/start-stop-daemon" chmod 755 "$TARGET/sbin/start-stop-daemon" ``` I also found the following entry in debootstrap's changelog which is interesting wrt. this discussion, from v1.0.52 (May 2013): ``` * scripts/sid, scripts/gutsy: Add a policy-rc.d, matching that in debian-installer-utils. This is the primary way to disable daemon startup. ```
Re: OpenLiteSpeed Build Script Violating Debian Upstream Guide
On 2020-03-08 Wookey wrote: [...] > So you need to package boringSSL before uploading this > package. [...] https://packages.qa.debian.org/android-platform-external-boringssl cu Andreas
Bug#953382: ITP: golang-github-tonistiigi-units -- Simple byte size formatting
Package: wnpp Severity: wishlist Owner: Tong Sun * Package name: golang-github-tonistiigi-units Version : 0.0~git20180711.6950e57-1 Upstream Author : Tõnis Tiigi * URL : https://github.com/tonistiigi/units * License : Expat Programming Lang: Go Description : Simple byte size formatting Simple byte size formatting. This package implements types that can be used in stdlib formatting functions like fmt.Printf to control the output of the expected printed string. Dependency of github.com/google/go-containerregistry & github.com/GoogleContainerTools/container-diff.
Re: apt 2.0 release notes
On 08.03.20 19:10, Jonas Smedegaard wrote: > Quoting Matthias Klose (2020-03-08 18:40:34) >> On 3/7/20 9:41 PM, Julian Andres Klode wrote: >>> # APT 2.0 >>> >>> After brewing in experimental for a while, and getting a first outing in >>> the Ubuntu 19.10 release; both as 1.9, APT 2.0 is now landing in unstable. >>> 1.10 would be a boring, weird number, eh? >>> >>> Compared to the 1.8 series, the APT 2.0 series features several new >>> features, >>> as well as improvements in performance, hardening. A lot of code has been >>> removed as well, reducing the size of the library. >> >> $ apt show >/dev/null | cat >> >> WARNING: apt does not have a stable CLI interface. Use with caution in >> scripts. >> >> Is there a roadmap when the CLI interface will become stable? > > I would not expect apt to ever get a stable interface for scripting. > > "man apt" says this in first paragraph of section DESCRIPTION: > >> apt provides a high-level commandline interface for the package >> management system. It is intended as an end user interface and enables >> some options better suited for interactive usage by default compared >> to more specialized APT tools like apt-get(8) and apt-cache(8). > > I.e. for scripting, use apt-get instead. If that last paragraph wants to say "use apt-get for scripting" then it should say it clearly and explicitly and not leave it up to sufficiently astute interpretation skills of the reader... *t
Re: not starting a daemon upon installation
On 07.03.20 21:30, Tomas Pospisek wrote: > tldr: why is not having a daemon started on install so involved? Can't > there be a better way? to which Jonas, Marco & jnqnfe replied (see thread). Thanks a lot Jonas, Marco & jnqnfe! *t
Bug#953390: ITP: golang-github-tonistiigi-fsutil -- Incremental file directory sync tools
Package: wnpp Severity: wishlist Owner: Tong Sun * Package name: golang-github-tonistiigi-fsutil Version : 0.0~git20200225.013a9fe-1 Upstream Author : Tõnis Tiigi * URL : https://github.com/tonistiigi/fsutil * License : Expat Programming Lang: Go Description : Incremental file directory sync tools in golang Incremental file directory sync tools in golang. Dependency of github.com/google/go-containerregistry & github.com/GoogleContainerTools/container-diff.
Re: debian/*.symbols files for C++ libraries
Hi! Chiming in too late I guess. On Sat, 29 Feb 2020 at 12:33, Mike Gabriel wrote: [snip] > > I've used it for other C++ packages with pretty good success. > > I have updated some of my C++ pkgs with .symbols files and it works > like charme. I tried the pkg-kde-tools at an earlier point (several > years ago) and wasn't happy with it. Well, to be honest, almost nothing changed in that side, maybe some substitution rule, but nothing more. And to be even more honest: the software was written by Modestas Vainius a long time ago, in perl. Modestas is no longer around and no one in the team is really fluent enough in perl to hack it. But it has been working all this time, which probably says a lot about it's quality :-) There was even an open bug to implement this directly into dpkg. I guess that if maybe someone takes the time to create a proper merge request it might finally be in, but that someone must understand perl to start with :-/ Kinds regards, Lisandro. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/
Re: not starting a daemon upon installation
On Sun, 2020-03-08 at 18:50 +0100, Marc Haber wrote: > debootstrap's files don't contain the string "divert". They do, > however, dump "exit 101" to $TARGET/usr/sbin/poliy-rc.d. I should issue a small correction to my earlier statement of live-build using a dpkg-divert of start-stop-daemon as its _single_ solution; working on the live-build codebase right now I bumped into its chroot_sysv-rc module and thus got a reminder that it does in fact also implement the policy-rc-d solution. so both debootstrap and livebuild both implement a form of both of these.
Bug#953403: ITP: golang-k8s-sigs-structured-merge-diff -- Test cases and implementation for "server-side apply"
Package: wnpp Severity: wishlist Owner: Tong Sun * Package name: golang-k8s-sigs-structured-merge-diff Version : 3.0.0-1 Upstream Author : Kubernetes SIGs * URL : https://github.com/kubernetes-sigs/structured-merge-diff * License : Apache-2.0 Programming Lang: Go Description : Implementation for "server-side apply" Structured Merge and Diff. It implements the Kubernetes "APPLY" operation, apart from the PUT/PATCH operations. Dependency of github.com/google/go-containerregistry & github.com/GoogleContainerTools/container-diff.
