Migration of packages blocked if (Build-)Depends are missing on some test architectures
Hi, I was wondering why the package drop-seq was not migrating. Testing excuses[1] says drop-seq-tools/arm64 has unsatisfiable dependency uninstallable on arch *, not running autopkgtest there While the package itself is Architecture: all it depends from picard-tools which is amd64 only. Thus the package does not install on other architectures. My fix for this problem was now to restrict the test architectures to amd64 only[2] - hoping that this will work. However, in general I think the testing migration should not prevented for the only reason that debci is trying to install a package on some architecture where it just can not be installed. I'd be really happy if this could be implemented in some way. Than the workaround[2] would not be needed any more. Kind regards Andreas. [1] https://qa.debian.org/excuses.php?package=drop-seq [2] https://salsa.debian.org/med-team/drop-seq/-/commit/3761c4c2dbf500d76f3a3a9aee99200a0eb34916 -- http://fam-tille.de
Re: Hurra for an efficient ftpmaster team!
Hi folks, seems it was 6 years ago - I stumbled upon this in my mailfolders by chance and I would love to repeat this wholeheartedly. Working on new software for Debian became way more fun since a couple of weeks! Thanks a lot to all members of the ftpmaster team Andreas. On Wed, Oct 22, 2014 at 07:04:43PM +0200, Jonas Smedegaard wrote: > Hi, > > I have to share with you all how very positively surprised I am by the > efficiency of the ftpmaster team processing the NEW queue. I feared > that we might experience extra slow processing this close to the freeze > but my experience have been quite the contrary. > > Hurra for the ftmaster team! > > I know processing is not always simple and that I might just have been > "lucky" lately (read: my recent uploads may simply be easy to handle). I > sure hope that not too many are sitting out there with the outright > opposite impression to mine, feeling abandoned by that moody and > mysterious "NEW". > > /me sends positive vibes towards ftpmasters and their machinery, > > - Jonas > > -- > * Jonas Smedegaard - idealist & Internet-arkitekt > * Tlf.: +45 40843136 Website: http://dr.jones.dk/ > > [x] quote me freely [ ] ask before reusing [ ] keep private -- http://fam-tille.de
Re: Split Packages files based on new section "buildlibs"
On Tue, 10 Nov 2020 at 20:29, Paul Wise wrote: > On Mon, Nov 9, 2020 at 10:37 PM Joerg Jaspert wrote: > > > More and more packages are being uploaded into the Debian archive which > > are only ever used for building packages. These are not only never > > intended to be installed onto an end-user's system, they are even > > actively discouraged from being used directly by a user. The two > > currently most notable examples are packages used by the Go and Rust > > programming languages and their ecosystem, but there well may be > > others[1]. > > Does this include the -dev packages for C/etc libraries? > No, those are useful for people writing C programs outside of packaging. > I guess it also applies to Haskell and other statically-linked languages. > > https://wiki.debian.org/StaticLinking It's not the static linking that's the issue, it's that go (and rust I assume) packages do not install things on the default search path of the compiler. I don't know whether haskell does or not. The -dev packages for C libraries definitely do! > The current proposal is to reduce the main Packages.xz files size by > > splitting[4] out all of the packages that are not intended for users, > > writing those into an own file. Those packages would have a section of > > "buildlibs", independent of their other properties. > > Should (almost?) everything in the existing libdevel section move to > the new buildlibs section? > I don't think so. Cheers, mwh
Re: Split Packages files based on new section "buildlibs"
Hi, Quoting Andrej Shadura (2020-11-10 10:27:44) > On Tue, 10 Nov 2020, at 08:28, Paul Wise wrote: > > > The current proposal is to reduce the main Packages.xz files size by > > > splitting[4] out all of the packages that are not intended for users, > > > writing those into an own file. Those packages would have a section of > > > "buildlibs", independent of their other properties. > > > Should (almost?) everything in the existing libdevel section move to > > the new buildlibs section? > > I wouldn’t say so. > > If I install, say, libftdi-dev, I expect to be able to do actual development > with it, for Debian or not. In fact, installing libftdi-dev would be the > first thing I do if I were to develop with the library. > > On the contrary, if I’m going to do some development with, say, clap (Rust > command-line arguments parser), I wouldn’t install librust-clap-dev; more > than that, if I actually did, I’d be very difficult for me to actually use it > to develop an app. I'm confused. We are packaging libraries of language X but then those packages will not be used by people who write software for language X on Debian? Intuitively, should I ever start with Rust, I would've thought that I had to install librust-clap-dev if I want to write code using "clap". What else would I install? If I understand the goal of "buildlibs" correctly, then it seems like quite a bit of a misnomer. The section will not focus on libraries to build stuff but on packages that are only ever used for Debian-internal stuff, so things I would not even need if I were to "build" software, right? Thanks! cheers, josch signature.asc Description: signature
Bug#974121: ITP: libcommonmark-perl -- Interface to the CommonMark C library
Package: wnpp Owner: Frédéric Bonnard Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libcommonmark-perl Version : 0.29 Upstream Author : Nick Wellnhofer * URL : https://metacpan.org/release/CommonMark * License : Artistic or GPL-1+ Programming Lang: Perl Description : Interface to the CommonMark C library libcommonmark-perl module is a wrapper around the official CommonMark C library libcmark. It closely follows the original API. The main module provides some entry points to parse documents and convenience functions for node creation. The bulk of features is available through CommonMark::Node objects of which the parse tree is made. CommonMark::Iterator is a useful class to walk through the nodes in a tree. CommonMark::Parser provides a push parser interface. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools. signature.asc Description: PGP signature
Re: Split Packages files based on new section "buildlibs"
On Tue, Nov 10, 2020 at 9:28 AM Andrej Shadura wrote: > Development packages for Rust and Go usually only ship source code. This reminds me of the proposal for installable source packages that one could (Build-)Depend on. Seems like that proposal would also solve the issue with Go and Rust, as well as end the need for the -source binary package workaround used by GCC and other packages. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Split Packages files based on new section "buildlibs"
On Tue, 10 Nov 2020 at 10:45:07 +0100, Johannes Schauer wrote: > I'm confused. We are packaging libraries of language X but then those packages > will not be used by people who write software for language X on Debian? > Intuitively, should I ever start with Rust, I would've thought that I had to > install librust-clap-dev if I want to write code using "clap". What else would > I install? The Rust community's expectation seems to be that you would install cargo, and use that to download and build the clap package directly from upstream, without apt/dpkg being involved at all. You would only use librust-clap-dev if you were building *a Debian package* that build-depends on librust-clap-dev (because we have a policy that our archive must be self-contained, so downloading dependencies using cargo is not allowed). smcv
Re: Mass bugs filing: autopkgtest must be marked superficial
Hi All, On Sun, Nov 8, 2020 at 10:28 PM Sudip Mukherjee wrote: > > Hi All, > > This is a new list for the autopkgtest superficial test. > > > Attached is the dd-list. Modified dd-list after discussion with the javascript maintainer team. -- Regards Sudip dd-list Description: Binary data
Bug#974126: ITP: libnet-dns-native-perl -- non-blocking system DNS resolver
Package: wnpp Owner: Frédéric Bonnard Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libnet-dns-native-perl Version : 0.22 Upstream Author : Oleg G * URL : https://metacpan.org/release/Net-DNS-Native * License : Artistic or GPL-1+ and LGPL-2+ Programming Lang: Perl Description : non-blocking system DNS resolver Net::Dns::Native provides several methods for host name resolution. It is designed to be used with event loops. All resolving are done by getaddrinfo(3) implemented in your system library. Since getaddrinfo() is blocking function and this class doesn't want to block, calls to this function will be done in separate thread. This class uses system native threads and not perl threads. So overhead shouldn't be too big. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools. signature.asc Description: PGP signature
Re: Migration of packages blocked if (Build-)Depends are missing on some test architectures
Hi Andreas, On Tue, Nov 10, 2020 at 09:32:46AM +0100, Andreas Tille wrote: > Hi, > > I was wondering why the package drop-seq was not migrating. Testing > excuses[1] says > >drop-seq-tools/arm64 has unsatisfiable dependency This is what's blocking you. >uninstallable on arch *, not running autopkgtest there Not this one. > While the package itself is > >Architecture: all > > it depends from picard-tools which is amd64 only. The release team recently swapped i386 for arm64 in "NOBREAKALL_ARCHES"[0][1]. That means that arch:all packages need to be installable on arm64 and yours isn't. AFAIK. > [ snip the rest which was about tests and I don't think that's the > problem here ] [0] https://salsa.debian.org/release-team/britney2/-/commit/5cb5235c06012b2a56e50e544f6cbe3adbbf35ab [1] https://salsa.debian.org/release-team/britney2/-/commit/2caf0fe4ea4de5541f3d8e71d5d69737f8d84fee -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#974119: ITP: ruby-terser -- Ruby wrapper for Terser JavaScript compressor
Package: wnpp Severity: wishlist Owner: Vivek K J X-Debbugs-Cc: debian-devel@lists.debian.org, vive...@protonmail.com * Package name: ruby-terser Version : 1.0.2 Upstream Author : Pavel Rosický * URL : http://http://github.com/ahorek/terser-ruby/ * License : MIT Programming Lang: Ruby Description : Ruby wrapper for Terser JavaScript compressor Terser minifies JavaScript files by wrapping TerserJS to be accessible in Ruby Hi Debian Maintainers, Terser is a ruby gem that helps to minify javascript files. since, the gem is not available in debian, I wish to pack that to debian. This debian package will be maintained by Debian Ruby Maintainers Team. The upstream of this gem is developed by Pavel Rosický and licensed under MIT license.The upstream is available at http://github.com/ahorek/terser-ruby. I think this gem will be helpful for ruby-gem developers. Thanks, VIVEK K J
Re: Migration of packages blocked if (Build-)Depends are missing on some test architectures
Hi Iain, On Tue, Nov 10, 2020 at 11:26:07AM +, Iain Lane wrote: > On Tue, Nov 10, 2020 at 09:32:46AM +0100, Andreas Tille wrote: > >drop-seq-tools/arm64 has unsatisfiable dependency > > This is what's blocking you. That's what I assumed. > >uninstallable on arch *, not running autopkgtest there > > Not this one. Yes, that's true but its part of my question: Why should all these tests be run if the dependencies are not available on that architecture. Wouldn't it be more sane to check dependencies first before running a test that will fail for sure? > > While the package itself is > > > >Architecture: all > > > > it depends from picard-tools which is amd64 only. > > The release team recently swapped i386 for arm64 in > "NOBREAKALL_ARCHES"[0][1]. That means that arch:all packages need to be > installable on arm64 and yours isn't. AFAIK. OK, fine. For the example drop-seq-tools I could make it Architecture: amd64 which is solving the current migration problem. However, I'm currently checking failing autopkgtests for Debian Med packages and add Architecture fields to debian/tests/control. In most cases this is perfectly easy auto-detectable from the package dependencies that the test will fail. I would love to see that dependency issue resolved by debci in the first place instead of assuming that maintainers will maintain this inside the control file. Chances are pretty good that once those dependencies might become available maintainers will simply forget to add a new architecture to debian/tests/control. That way we might hide future tests on those architectures from debci. > > [ snip the rest which was about tests and I don't think that's the > > problem here ] Not really. My example was possibly not the best - I hope I was able to clarify this now. Kind regards Andreas. > [0] > https://salsa.debian.org/release-team/britney2/-/commit/5cb5235c06012b2a56e50e544f6cbe3adbbf35ab > [1] > https://salsa.debian.org/release-team/britney2/-/commit/2caf0fe4ea4de5541f3d8e71d5d69737f8d84fee -- http://fam-tille.de
Bug#974141: ITP: fcitx5-chewing -- Chewing support for fcitx5
Package: wnpp Severity: wishlist Owner: Yao Wei (魏銘廷) X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: fcitx5-chewing Version : 5.0.1 Upstream Author : Weng Xuetian * URL : https://github.com/fcitx/fcitx5-chewing * License : GPL-2+ Programming Lang: C Description : Chewing support for fcitx5 This package is the support library for fcitx5 to use Chewing input method, which is one of the popular Zhuyin input method for traditional Chinese. This package should be maintained by Debian Input Method Team.
Re: Migration of packages blocked if (Build-)Depends are missing on some test architectures
Hi Andreas, On 10-11-2020 13:21, Andreas Tille wrote: > Yes, that's true but its part of my question: Why should all these > tests be run if the dependencies are not available on that architecture. > Wouldn't it be more sane to check dependencies first before running > a test that will fail for sure? The are not running, clearly, as the text says. But you are wondering if we should not put that text there because it confuses you? Because other people may be wondering why they are not seeing the results. >>> While the package itself is >>> >>>Architecture: all >>> >>> it depends from picard-tools which is amd64 only. >> >> The release team recently swapped i386 for arm64 in >> "NOBREAKALL_ARCHES"[0][1]. That means that arch:all packages need to be >> installable on arm64 and yours isn't. AFAIK. > > OK, fine. For the example drop-seq-tools I could make it > > Architecture: amd64 > > which is solving the current migration problem. However, I'm currently > checking failing autopkgtests for Debian Med packages and add > Architecture fields to debian/tests/control. In most cases this is > perfectly easy auto-detectable from the package dependencies that the > test will fail. Please elaborate. In my experience, things only go ill when package build both arch:all and some arch specific packages, as in that case the migration software just doesn't have enough information available. > I would love to see that dependency issue resolved by > debci in the first place instead of assuming that maintainers will > maintain this inside the control file. Chances are pretty good that > once those dependencies might become available maintainers will simply > forget to add a new architecture to debian/tests/control. That way we > might hide future tests on those architectures from debci. Yes, that's something I worry about too, but I also don't have a better solution with the current information available to the migration software. Obviously we could expend that, but that has a rather high price so we better design it well and balance pro's and con's. Paul signature.asc Description: OpenPGP digital signature
Bug#974156: ITP: ezdxf -- Python package to create and modify DXF drawings
Package: wnpp Severity: wishlist Owner: Bdale Garbee X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: ezdxf Version : 0.14.2 Upstream Author : Manfred Moitzi * URL : https://ezdxf.mozman.at * License : MIT Programming Lang: Python Description : Python package to create and modify DXF drawings Python package to create and modify DXF drawings, independent from the DXF version. You can open/save every DXF file without losing any content (except comments). Unknown tags in the DXF file will be ignored but preserved for saving. With this behavior it is possible to open also DXF drawings that contains data from 3rd party applications. Petter Reinholdtsen and I are collaborating to package this, which is a dependency for the openmotor package I'm also working on. Bdale
Bug#974160: ITP: scikit-fmm -- Python module which implements the fast marching method
Package: wnpp Severity: wishlist Owner: Bdale Garbee X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: scikit-fmm Version : 2019.1.30 Upstream Author : The scikit-fmm team * URL : http://packages.python.org/scikit-fmm * License : BSD Programming Lang: Python, C/C++ Description : Python module which implements the fast marching method Python module which implements the fast marching method. The fast marching method is used to model the evolution of boundaries and interfaces in a variety of application areas. More specifically, the fast marching method is a numerical technique for finding approximate solutions to boundary value problems of the Eikonal equation: F(x) | grad T(x) | = 1 Typically, such a problem describes the evolution of a closed curve as a function of time T with speed F(x)>0 in the normal direction at a point x on the curve. The speed function is specified, and the time at which the contour crosses a point x is obtained by solving the equation. scikit-fmm is a simple module which provides functions to calculate the signed distance and travel time to an interface described by the zero contour of the input array phi. Petter Reinholdtsen and I are collaborating on packaging this as it is a build dependency for the openmotor package I am also working on. Bdale
Bug#974161: ITP: openmotor -- internal ballistics simulator for rocket motor experimenters
Package: wnpp Severity: wishlist Owner: Bdale Garbee X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: openmotor Version : 0.4.0 Upstream Author : https://github.com/reilleya * URL : https://github.com/reilleya/openMotor * License : GPL Programming Lang: Python Description : internal ballistics simulator for rocket motor exper openMotor is an open-source internal ballistics simulator for rocket motor experimenters. The software produces estimates of a rocket motor's chamber pressure and thrust based on input such as propellant properties and grain geometry. It uses the Fast Marching Method to determine how a propellant grain regresses, which allows the use of arbitrary core geometries. Current Features: * Metric and imperial units * Support for common grain geometries such as BATES, Finocyl, Star and more * Loading custom grain geometry from DXF files * A propellant editor that allows the user to enter the properties of as many propellants as they wish * The grain editor displays how a grain will regress to cut down on the guesswork involved in tweaking geometry * ENG file exporting * Burnsim importing and exporting * A UI that supports saving and loading designs along with undo and redo. Planned Features: * Erosivity simulation * Detailed output of every calculated parameter at any time and position along the motor
Bug#974163: ITP: kpeoplevcard -- KPeople vCard plugin for KDE Connect
Package: wnpp Severity: wishlist Owner: Aurélien COUDERC X-Debbugs-Cc: debian-devel@lists.debian.org, debian-qt-...@lists.debian.org * Package name: kpeoplevcard Version : 0.1 Upstream Author : KDE PIM Developers * URL : https://invent.kde.org/pim/kpeoplevcard * License : LGPL-2.1+ Programming Lang: C++ Description : KPeople vCard plugin for KDE Connect KPeople is the KDE framework offering unified access to your contacts from different sources, grouping them by person while still exposing all the data. This plugin provides the backend to KDE Connect for manipulating the vCard format. The package will be maintained under the Debian Qt/KDE Maintainers’ umbrella.
Bug#974165: ITP: vtk9 -- Visualization Toolkit (VTK) version 9
Package: wnpp Severity: wishlist Owner: Anton Gladky X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: vtk9 Version : 9.0.1 Upstream Author : Kitware * URL : https://vtk.org/ * License : BSD Programming Lang: C++ Description : Visualization Toolkit (VTK) version 9 The Visualization Toolkit (VTK) is an open-source, freely available software system for 3D computer graphics, image processing and visualization. VTK consists of a C++ class library and several interpreted interface layers including Tcl/Tk, Java, and Python. Kitware, whose team created and continues to extend the toolkit, offers professional support and consulting services for VTK. VTK supports a wide variety of visualization algorithms including: scalar, vector, tensor, texture, and volumetric methods; and advanced modeling techniques such as: implicit modeling, polygon reduction, mesh smoothing, cutting, contouring, and Delaunay triangulation. VTK has an extensive information visualization framework, has a suite of 3D interaction widgets, supports parallel processing, and integrates with various databases on GUI toolkits such as Qt and Tk. VTK is cross-platform and runs on Linux, Windows, Mac and Unix platforms. The package will be maintained in Debian Science Team. -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAl+q/uMRHGdsYWRrQGRl Ymlhbi5vcmcACgkQ0+Fzg8+n/waD1Q/+MG8sD33Jbf/mBv/dVg69iQEtMpA9lgVW +WHV8o5WWpU1qrPKd37odKklWx0vmENGxFdioz86RQOy4JKA2ZYeBmvKIvUftL7R wshkHo2bM6IYjqtOCg419uIKtrOFK1nNgEnTQRQBrZqRYT9GHZbZJpaDsVmA5Iyy xONU/V9nP5hlcyQm6m2j0YKi1c71ulps8MMf05SsDcJiIbQOTEjSWusHBAIGfOH4 qI11NH+O9Ay5W7pQBMv9TN1ZJfNFP6Jbu0xeoE/AutgroLg0TOunnAze7bp1oBtY JodjQUAqK4qoYBahbsIklZ1F4QGVFdPOJbrkBAQg/0XhtTEevHNJpFU3Q2k7kHrC 2d+i6dap8HENiJQ2loQrjqQQI1dvISMSym6cVm6hVsFUBoQLDeR4sSUByWkOZX6F k/fVHRn9ieIONOR1hYjrKWcqpkn8lx52uHAN800QGMCJF27lK/Nqkhe3hsuzBD8S WTrAwewOq6kdUDa2ZxrEyQsByCfiIV0Itbq1JvkbED/nwu+pXmjCcDBzvz5Cz/Wd MR1lRT2VWvw402+Y9KVmwicm8QjTva0YZyavbhqutioRX4fJf+36SMnFqv/TGCCY fW7Ag0EeWmV8Go9TiqG10uywmwFKz7aUEHGeNJKNaJDXRxKcaJV6WhR3M41/5ZkM ifu5HOAX+TE= =XSAj -END PGP SIGNATURE-
Re: Split Packages files based on new section "buildlibs"
On 15948 March 1977, Paul Wise wrote: Does this include the -dev packages for C/etc libraries? No. I guess it also applies to Haskell and other statically-linked languages. https://wiki.debian.org/StaticLinking StaticLinking itself is not enough. This is about languages where the actual development in it is discouraged from doing with the debian packaged stuff. Where you do not go "I need lib XY, i install libxy-perl/libxy-dev/whatever the name" and hack around using it. But "Oh, i want to hack on foo, i go get foo/cargo .../whateverthetool" and the debian package only ever comes in play if you do build debian packages using it. The current proposal is to reduce the main Packages.xz files size by splitting[4] out all of the packages that are not intended for users, writing those into an own file. Those packages would have a section of "buildlibs", independent of their other properties. Should (almost?) everything in the existing libdevel section move to the new buildlibs section? No, if so we would have split that section out. -- bye, Joerg
Re: Split Packages files based on new section "buildlibs"
On Tue, 2020-11-10 at 10:07 +, Simon McVittie wrote: > On Tue, 10 Nov 2020 at 10:45:07 +0100, Johannes Schauer wrote: > > I'm confused. We are packaging libraries of language X but then those > > packages > > will not be used by people who write software for language X on > > Debian? > > Intuitively, should I ever start with Rust, I would've thought that I > > had to > > install librust-clap-dev if I want to write code using "clap". What > > else would > > I install? > > The Rust community's expectation seems to be that you would install > cargo, > and use that to download and build the clap package directly from > upstream, > without apt/dpkg being involved at all. I don't know that that means we should abandon efforts to integrate the debian packages into usable code. Rubygems has a similar expectation: however, there is a package (rubygems- integration) that makes it work anyways. With Ruby, the only (user- obvious) difference between installing via gem and via deb is the package version. What about Rust makes that impossible? Pip packages are the same, but they are designed that way, so I don't count it. NPM packages aren't quite as well integrated (or maybe they just update too fast), but they are still used. There might be something about how cargo works that makes this kind of integration impossible, similar to how the Nix package manager doesn't play well with others. But I don't think we should just segregate Rust libraries to a corner of the archive without at least considering it. Thanks, Calum M. signature.asc Description: This is a digitally signed message part
Re: restarting instanced systemd services on upgrade
Hi Simon, once again, thanks a lot. I have now tried out your suggestion and it works nicely. Just to make sure, I have now the following units, see below. I am aware that the system instantiation service onedrive@ is not optimal since it expects $HOME to be /home/%i, but let us leave this aside for now. I will document other options like lingering etc. Please let me know any comments/improvements for the units you might see. Thanks again and best regards Norbert /lib/systemd/system/onedrive.target --- [Unit] Description=OneDrive Master Before=multi-user.target [Install] WantedBy=multi-user.target /lib/systemd/system/onedrive@.service -- [Unit] Description=OneDrive Free Client for %i Documentation=https://github.com/abraunegg/onedrive After=network-online.target Wants=network-online.target PartOf=onedrive.target [Service] ExecStart=/usr/bin/onedrive --monitor --confdir=/home/%i/.config/onedrive User=%i Group=users Restart=on-failure RestartSec=3 RestartPreventExitStatus=3 [Install] WantedBy=multi-user.target /usr/lib/systemd/user/onedrive.service -- [Unit] Description=OneDrive Free Client Documentation=https://github.com/abraunegg/onedrive After=network-online.target Wants=network-online.target PartOf=onedrive.target [Service] ExecStart=/usr/bin/onedrive --monitor Restart=on-failure RestartSec=3 RestartPreventExitStatus=3 [Install] WantedBy=default.target -- PREINING Norbert https://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Re: Split Packages files based on new section "buildlibs"
On 15949 March 1977, Calum McConnell wrote: The Rust community's expectation seems to be that you would install cargo, and use that to download and build the clap package directly from upstream, without apt/dpkg being involved at all. I don't know that that means we should abandon efforts to integrate the debian packages into usable code. [...] There might be something about how cargo works that makes this kind of integration impossible, similar to how the Nix package manager doesn't play well with others. But I don't think we should just segregate Rust libraries to a corner of the archive without at least considering it. While I do think its kind of foolish to assume the rust people in Debian haven't thought if its feasible to do so (or not), the best way to find out is talking to them. I found them quite helpful and friendly, even when I told them that their way is not what we want in Debian. I mean, I block their most preferred way from (continuing to) enter Debian, the rest of the team tells them similar for a longish time, so if it would be easy to just flip something and be "more debian like", I do think it would have been used. Of course, if you find the magic, all the better. And if that way comes around in a year or three, the proposal here makes it *easy* (archive side) to "switch them back into the main packages file". -- bye, Joerg
