Bug#917281: ITP: ruby-kitchen-salt -- salt provisioner for test-kitchen
Package: wnpp Severity: wishlist Owner: Mathieu Parent * Package name: ruby-kitchen-salt Version : 0.4.0 Upstream Author : SaltStack Inc * URL : https://github.com/saltstack/kitchen-salt * License : MIT Programming Lang: Ruby Description : salt provisioner for test-kitchen salt provisioner for test-kitchen so that you can test all the things (under the ruby-extras team)
Bug#917282: ITP: lz4json -- unpack lz4json files, usually generated by Mozilla programs
Package: wnpp Severity: wishlist Owner: Adam Borowski * Package name: lz4json Version : ? Upstream Author : Andi Kleen * URL : https://github.com/andikleen/lz4json * License : BSD-2 ish Programming Lang: C Description : unpack lz4json files, usually generated by Mozilla programs Instead of a standard .json.lz4, Firefox uses its own format to compress its bookmarks and session restore files. This tool lets you read them, converting to json. Going from json to a human-readable format is then up to you.
Re: fuse -> fuse3
On Fri, Dec 21, 2018 at 11:03:34PM +0100, Oibaf wrote: > The package fuse3 is available since awhile in sid/buster. > Their users however are still using old fuse (v2), e.g. sshfs-fuse. > According to this: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912528 > fuse3 is not co-installable with fuse, but a patch is available. > > So is there a chance this get fixed and sshfs-fuse and other package can be > updated to use fuse3 for buster? Thanks for mentioning it! I didn't even *know* about the existence of fuse3. Is libfuse3 API compatible with fuse2? In other words, is it just a recompile away for e2fsprogs to be able to produce a fuse2fs binary that works with fuse3? If so, I wonder if we would be better off renaming libfuse3-dev to something like fuse-dev? That would mean that people who just recompiled their packages would pick up fuse3 support. It would also make it easier for people like myself, who try to make e2fsprogs and its debian packaging trivially backportable to stable, old-stable, and old-old-stable. Well, it would still be annoying in the short-term, since I'll have to teach my scripts how to generate a different debian/control from debian/control.in so that we use libfuse2-dev for pre-Buster, and libfuse3-dev or fuse-dev for Buster+. But if we chase things so that it's fuse-dev for Buster+. in the future it will be easier to support debian packaging trivially for muliple Debian releases. Cheers, - Ted P.S. If fuse3 and fuse are not co-installable, we really should have managed this as a formal buster migration earlier. Oh, well, water under the bridge, but we're going to have to move briskly before the Debian Buster transition freeze of January 12, 2019. :-/
Proposal: Repository for fast-paced package backports
Heisann, alle sammen, as announced in the recent thread about maintaining, I hereby propose a repository that allows making “backports” of packages available to users of the stable distribution, if those packages cannot be maintained in testing and backported in the usual way. If you are interested in what lead up to that, please see bug #915050. I will give a short summary of it here. Reasons for having a special place for some packages (You may want to skip this part if you are familiar with the situation.) As all developers know (but passers-by may not), for software to enter the Debian archive, it is always uploaded to the unstable distribution, then migrates to testing (hopefully ;)), which is at some point snapshot and made the new stable release. From there on, maintainers have two obligations: Firstly, keep the package in stable good and secure, e.g. by uploading security fixes for it once they become available upstream, or even backport fixes themselves. Secondly, provide the package in unstable with updates and ensure its migration, to keep it ready for the next stable release. Now, for some software packages, this process is problematic, because upstream may have another idea about software lifecycles. Concerning the GitLab example, upstream provides security fixes for three months for their stable releases. Backporting fixes from newer versions is very hard or impossible because the massive amounts of changes to the software in every new versions. This is something that also affects other packages, like Mozilla Firefox, which has a firefox package in unstable, and a separate firefox-esr package, with the ESR version of Firefox. Only the latter migrates to testing. Users of Debian honour it for its stability, but as an agile software lifecycle is adapted by more and more very popular software packages, not being able to install these packages in the trusted, well-known fashion through the official apt repositories is becoming more and more of a drawback. It can easily be assumed that the normal release and maintenance cycle of Debian stable will not change, which is very good, so we should find a way to still provide such software as described above to users. Why backports is not enough === This also is well-known, but for completeness: Formal backports in stable-backports are required to be direct backports from testing, and are a stepping stone within the upgrade from stable to stable+1. Thus, a version of a package that is not in testing can never be in stable-backports. Name of the new repository == In the past, the name “volatile” was used for a similar repository, but with a different scope (limited to data packages for things like virus scanners). I will thus use the working title volatile throughout this proposal, although this may change. Other ideas: fastlane, unsupported (Please feel free to add other ideas.) Requirements for a package to go into stable-volatile = The new volatile proposal is not intended to ease life for package maintainers who want to bypass the migration and QA requirements of the regular stable lifecycle, so special need must be taken to ensure only packages that need it go into volatile. I want to summarise the requirements like so: - The package must be maintained in unstable, like every other package. - The package must not be in testing, and care must be taken for the package not to migrate to testing. - Regular maintenance for the lifetime of stable must be impossible or unnecessarily hard, and this requirement should be assessed in a verifiable manner, e.g. referring to upstream’s lifecycle model. - There must be notable need for the package. Like for backports, user requests might be an indicator. - Should the package be removed from unstable, it must also be removed from volatile. - Should the package begin to migrate to testing again, it must be moved to stable-backports. Before starting to maintain a volatile package, the maintainer shall seek consent (or doubt) on debian-devel. Building packages and package dependencies == Packages for volatile are built the same way as formal backports, only that the source is taken from unstable rather than testing. In particular: - Changes shall be kept as small as possible. - The package is rebuilt against stable. - The package may depend on packages in stable, stable-backports or stable-volatile. Dependencies on other packages in volatile should be avoided if possible. Especially, dependencies of the package that also need backporting must not be added to volatile just because they are dependencies — every dependency that is needed to be backported to support the volatile package must be considered on its own and in all but unprobable edge cases be maintained as a formal b
Re: Proposal: Repository for fast-paced package backports
On Tue, 25 Dec 2018, Dominik George wrote: > Heisann, alle sammen, > > as announced in the recent thread about maintaining, I hereby propose a > repository that allows making “backports” of packages available to users > of the stable distribution, if those packages cannot be maintained in > testing and backported in the usual way. If you are interested in what > lead up to that, please see bug #915050. I will give a short summary of > it here. > > > Reasons for having a special place for some packages > > > (You may want to skip this part if you are familiar with the situation.) > > As all developers know (but passers-by may not), for software to enter > the Debian archive, it is always uploaded to the unstable distribution, > then migrates to testing (hopefully ;)), which is at some point snapshot > and made the new stable release. From there on, maintainers have two > obligations: Firstly, keep the package in stable good and secure, e.g. > by uploading security fixes for it once they become available upstream, > or even backport fixes themselves. Secondly, provide the package in > unstable with updates and ensure its migration, to keep it ready for the > next stable release. > > Now, for some software packages, this process is problematic, because > upstream may have another idea about software lifecycles. Concerning the > GitLab example, upstream provides security fixes for three months for > their stable releases. Backporting fixes from newer versions is very > hard or impossible because the massive amounts of changes to the > software in every new versions. This is something that also affects > other packages, like Mozilla Firefox, which has a firefox package in > unstable, and a separate firefox-esr package, with the ESR version of > Firefox. Only the latter migrates to testing. > > Users of Debian honour it for its stability, but as an agile software > lifecycle is adapted by more and more very popular software packages, > not being able to install these packages in the trusted, well-known > fashion through the official apt repositories is becoming more and more > of a drawback. > > It can easily be assumed that the normal release and maintenance cycle > of Debian stable will not change, which is very good, so we should find > a way to still provide such software as described above to users. > > > Why backports is not enough > === > > This also is well-known, but for completeness: Formal backports in > stable-backports are required to be direct backports from testing, and > are a stepping stone within the upgrade from stable to stable+1. Thus, a > version of a package that is not in testing can never be in > stable-backports. > > > Name of the new repository > == > > In the past, the name “volatile” was used for a similar repository, but > with a different scope (limited to data packages for things like virus > scanners). I will thus use the working title volatile throughout this > proposal, although this may change. > > Other ideas: fastlane, unsupported > > (Please feel free to add other ideas.) > > > Requirements for a package to go into stable-volatile > = > > The new volatile proposal is not intended to ease life for package > maintainers who want to bypass the migration and QA requirements of the > regular stable lifecycle, so special need must be taken to ensure only > packages that need it go into volatile. I want to summarise the > requirements like so: > > - The package must be maintained in unstable, like every other package. > - The package must not be in testing, and care must be taken for the >package not to migrate to testing. > - Regular maintenance for the lifetime of stable must be impossible >or unnecessarily hard, and this requirement should be assessed in >a verifiable manner, e.g. referring to upstream’s lifecycle model. > - There must be notable need for the package. Like for backports, user >requests might be an indicator. > - Should the package be removed from unstable, it must also be removed >from volatile. > - Should the package begin to migrate to testing again, it must >be moved to stable-backports. > > Before starting to maintain a volatile package, the maintainer shall > seek consent (or doubt) on debian-devel. > > > Building packages and package dependencies > == > > Packages for volatile are built the same way as formal backports, only > that the source is taken from unstable rather than testing. In > particular: > > - Changes shall be kept as small as possible. > - The package is rebuilt against stable. > - The package may depend on packages in stable, stable-backports or > stable-volatile. > > Dependencies on other packages in volatile should be avoided if > possible. Especially, dependencies of the package that al
Re: Proposal: Repository for fast-paced package backports
> We already told you to build your own repo. You should probably start with identifying the senders of mail correctly ☺. I am not the gitlab maintainer (and will never be). > Imho you should start the same way backports started - outside of > debian. > Prove that it works and integrate into Debian later. I would agree with you if it were a big change - however, the proposal has a very low impact, if not none at all, on existing stuff. In contrast to what you seem to believe (accuse people of…), this proposal is about helping Debian as a whole, not forcing a certain package into the distribution. gitlab only serves as an example of why it is useful. The Debian infrastructure already supports everything that is needed to implement this, and starting with parallel infrastructure would probably mean that it will fail because this requires a single person spending time and money to maintain the infrastructure (which is otherwise already there), and to make it really work, this is a low (think of buildds, etc.). In any case, I do not see why you would fight the fact that someone makes a detailed proposal. A proposal can be accepted or denied, of course, but your tone implies you think noone should have made the proposal i nthe first place. Please don't fight people wanting to help based on your opinion about a prior case around gitlab. -nik signature.asc Description: PGP signature
Re: Proposal: Repository for fast-paced package backports
On Tue, 25 Dec 2018, Dominik George wrote: > > We already told you to build your own repo. > > You should probably start with identifying the senders of mail > correctly ☺. I am not the gitlab maintainer (and will never be). https://lists.debian.org/debian-backports/2018/12/msg00028.html This wasn't about gitlab. > > > Imho you should start the same way backports started - outside of > > debian. > > Prove that it works and integrate into Debian later. > > I would agree with you if it were a big change - however, the proposal > has a very low impact, if not none at all, on existing stuff. In > contrast to what you seem to believe (accuse people of…), this proposal > is about helping Debian as a whole, not forcing a certain package into > the distribution. gitlab only serves as an example of why it is useful. > The Debian infrastructure already supports everything that is needed to > implement this, and starting with parallel infrastructure would probably > mean that it will fail because this requires a single person spending > time and money to maintain the infrastructure (which is otherwise > already there), and to make it really work, this is a low (think of > buildds, etc.). > > In any case, I do not see why you would fight the fact that someone > makes a detailed proposal. A proposal can be accepted or denied, of > course, but your tone implies you think noone should have made the > proposal i nthe first place. > > Please don't fight people wanting to help based on your opinion about a > prior case around gitlab. I don't fight against it. I just want to keep it away from backports, thats not the same. Alex signature.asc Description: PGP signature
Re: Proposal: Repository for fast-paced package backports
On Tue, Dec 25, 2018 at 10:11:43PM +0100, Alexander Wirt wrote: > https://lists.debian.org/debian-backports/2018/12/msg00028.html > > This wasn't about gitlab. Oh. I must have misread the "gitlab" in the subject, along withthe mail being sent to the gitlab maintainer, a gitlab bugreport in the BTS, and concerning a request to accept gitlab into backports ;). Still, there's a big difference: * The thread you refer to is about uploading to backports. This proposal ia about *not* uploading to backports. The newly-proposed section is only intended to co-exist with backports, and interact nicely with backports. (Mind the difference between backport as a general term for a package made available for an older distribution, and the name backports for a section in the Debian repository). * Your mail you are referring to talks about "backports" from unstable being a different workflow - this proposal proposes such a workflow. * Your mail refers to packages being indistinguishable in -backports - this proposal is all about having a new section in the repository to distinguish them. In short: This proposal addresses the exact concerns you raised before )although I am not the person you expressed them towards). -nik signature.asc Description: PGP signature
Re: Proposal: Repository for fast-paced package backports
> In short: This proposal addresses the exact concerns you raised before > )although I am not the person you expressed them towards). Well, sure, I was involved in that thread, but only in the way that I announced a proposal (this one). Not in any of the stuff concerning adding something to -backports. -nik signature.asc Description: PGP signature
Bug#917305: ITP: dictzip-java -- DictZip library for Java
Package: wnpp Severity: wishlist Owner: Andrej Shadura -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: dictzip-java Version : 0.8.2 Upstream Author : Hiroshi Miura * URL : https://github.com/dictzip/dictzip-java * License : GPL-2+ with Classpath exception Programming Lang: Java Description : DictZip library for Java This package provides a Java library to access dictionary databases compressed with the LZ77 algorithm in a manner which is completely compatible with gzip(1), but using an extension that allows for random access to chunks of about 57kB without the overhead of decompressing the entire file. This package is a dependency of OmegaT, a CAT tool. -BEGIN PGP SIGNATURE- iQFIBAEBCAAyFiEEeuS9ZL8A0js0NGiOXkCM2RzYOdIFAlwisGIUHGFuZHJld3No QGRlYmlhbi5vcmcACgkQXkCM2RzYOdIvNQf7B7RmyHsfS/tq7z6BPqo/7iTh3WpV hnNGQT7V0eRftAYJFKpeHkiTIeIahGRbAlDYAGApNMa09GbIYqW5QG7Gd2DNE5j8 TmlUrlM8PWiy9YHEAqp0f80/4Sb4hLWtLBiyAdPEzPwO3n21WVJYzfhyNDzDyaau 1jpxGut3HnBONNydO6aV9EmtbS4xZrBgYc4AEOk41lhU+20ujRVYmD981FUDlgRN FkhMeTz2q32J/yizG42NXrxLXmuKKAo7pPsEP5Wr1NdvspzYMAg4b2WHZa3MBuOb IRZttX6c7C19SlATqFhhpUdq5cuclUwy9+6wIlRe213X9yyGH8xdxRzRyw== =tsL+ -END PGP SIGNATURE-
Re: Proposal: Repository for fast-paced package backports
Hi, >having read the whole Gitlab discussion, I still don't get how/why the >new repository depends or relates to backports. Instead it could be >self-contained, except for stuff already available in stable. Couldn't >you roll the new repository entirely independent of any backports? Even >if you say there won't be any additional work for the backport policy >owners, letting a new repo depend on backports will implicitly have an >impact, which doesn't sound fully thought through yet. This is answered in the proposal. The reason is to not have volatile abused to ease backporting, and to allow packages to easily move back to backports again. >I consider especially copying parts of the version scheme fairly >confusing. This gives your concept a bad touch of just trying to work >around established rules (i.e. backports rules). Instead of defining >such minor facets I would recommend you to work on clarity about what >rules you want to establish in the new repo instead. I am a bit disappointed that my efforts to emphasize good compatibility with established processes is interpreted that way. As I already laid out several times during the last days, I am in fact disappointed that assuming bad or egoistic intentions seems to have become normal in Debian. That said, the version numbering is a way to ensure work *with* established rules, not around. >Also, as Alex suggested, I would prefer if such experiments could be >started outside the official Debian archive, like backports once >successfully did. Given how much efforts it took to get backports >integrated officially, I don't consider adding a new repo a minor >change. Did you discuss your idea with ftp masters, dak maintainers, >and buildd admins before? I did not discuss this proposal before discussing this proposal, no. That's why I am discussing this proposal :). If you read it properly, you will find that does not add anything really new, but extends something existing - yet without interfering with it much. >I acknowledge that Debian needs a solution to support fast moving >projects like Gitlab better than now. Yet, without a *proof* of concept >how this could work out in the long run (i.e. across more than one >Debian release cycle), I don't think it is the right time to ask for >such a big change now. Again, the change is not new - it is an extension of backports, using the exact same concepts and rules, apart from the source distribution and the target directory. It is an extension designed to play very nicely with backports. > I consider Debian open enough to support such >concepts outside the official archive first. I hope that e.g. official buildds will not grab code from my private machine and build it, for example. -nik
Re: Proposal: Repository for fast-paced package backports
Hi all, having read the whole Gitlab discussion, I still don't get how/why the new repository depends or relates to backports. Instead it could be self-contained, except for stuff already available in stable. Couldn't you roll the new repository entirely independent of any backports? Even if you say there won't be any additional work for the backport policy owners, letting a new repo depend on backports will implicitly have an impact, which doesn't sound fully thought through yet. I consider especially copying parts of the version scheme fairly confusing. This gives your concept a bad touch of just trying to work around established rules (i.e. backports rules). Instead of defining such minor facets I would recommend you to work on clarity about what rules you want to establish in the new repo instead. Also, as Alex suggested, I would prefer if such experiments could be started outside the official Debian archive, like backports once successfully did. Given how much efforts it took to get backports integrated officially, I don't consider adding a new repo a minor change. Did you discuss your idea with ftp masters, dak maintainers, and buildd admins before? I acknowledge that Debian needs a solution to support fast moving projects like Gitlab better than now. Yet, without a *proof* of concept how this could work out in the long run (i.e. across more than one Debian release cycle), I don't think it is the right time to ask for such a big change now. I consider Debian open enough to support such concepts outside the official archive first. Kind regards, Micha
Re: Proposal: Repository for fast-paced package backports
Hi, I like the general direction, but there are some aspects of your >proposal >which should be improved. Thanks! >> Other ideas: fastlane, unsupported > >Or maybe something like "fastpaced", after all this repo would not be >unsupported at all, the very point is to provide actual support after >all. I actually think volatile is a good name. After all, it's not so far from the previous volatile. >> - The package must be maintained in unstable, like every other >package. > >Given the nature of the packages in "fastpaced", it's counterproductive >to mandate the same standards as for the standard archive, it rather >makes >sense to relax some aspects. > >E.g. we usually try to avoid embedded code copies. But for a package >like Gitlab that doesn't really add any value, if an embedded Ruby >package is affected, Gitlab upstream fixes it in their weekly release >anyway. And if not using the embedded code copies you'll end up with >plenty of >dependencies which can no longer be fulfilled from stable as upstream >moves forward. The intention is to keep the way open to have a real backport again should the situation change. I find that very important for compatibility and assuring upgrade paths. >> I propose to add the volatile repository next to the backports >> repository, and treat it as part of backports. > >I wouldn't tie this to backports at all, rather make it a separate >section of the archive and have some ACL mechanism to allow the DDs >maintaining a fastpaced package to grant access to it (similar to >#817285). I am open to this, as long as the goals to have full compatibility with backports stay the same. -nik
Re: Bug#915407: libpam-systemd: please add a virtual package "logind" to allow alternatives
On Mon, Dec 24, 2018 at 05:37:56PM -0300, Felipe Sateler wrote: > On Sat, Dec 22, 2018 at 5:33 PM Adam Borowski wrote: > > Could you please either take this patch or propose a different approach? > > I have received no feedback other than a brief unconclusive remark on IRC. > > Sorry for the radio silence. Let's try to remedy that. Thank you for moving this forward! > > opt-in for every depender on libpam-systemd > > This is a good feature of the proposal: it requires explicit opt-in by > reverse dependencies. > > Thus: if package X and Y need APIs that elogind provides, they'd be changed > > to: > > Depends: default-logind | logind > > while package Z that needs a "bring-me-pink-pony" function will not. > > I (not speaking for the whole team), have no objection to this patch. > However, it was pointed out to me that virtual packages require policy > updates[1], first starting as a debian-devel discussion. So I'm starting > this now Right. In the meantime, you can test using libpam-elogind-compat which is a hack that Provides: a real package. This lacks the opt-in effect, but outside of packaging metadata should work the same. > The proposed virtual packages are: > > logind: a org.freedesktop.login1 D-Bus API implementation > default-logind: should be provided by the distributions default logind > provider (currently pam-systemd) > > Background: currently libpam-systemd provides two features currently used > by third parties: one is the necessary hooks to start the systemd > implementation of login1. The second is hooking up the systemd --user > service manager. This virtual package attempts to disentangle the two so > that packages that only require logind can use an alternative > implementation. Not sure if it's worth noting that the Provides must, and Depends can, be versioned. This allows requiring a certain level of the API. > Adam/other elogind maintainers, please clarify/improve wording if this was > somehow inaccurate. Looks good to me, thank you! Meow. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Ivan was a worldly man: born in St. Petersburg, raised in ⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned ⠈⠳⣄ to the city of his birth to die.
Re: Policy and procedures issue: init package hijacked via hostile NMU (declined by maintainers)
Andreas Henriksson writes ("Re: Policy and procedures issue: init package
hijacked via hostile NMU (declined by maintainers)"):
> I have only seen a limited amount of Dmitrys work, but my impression
> is that he's not someone who should be trusted with unrestricted
> uploading privileges. I think fast-tracking him through NM was
> a mistake and would suggest he should take the full tour.
I agree with Guillem's posts to this thread. But also I wanted to say
something nice about Dmitry.
I have had cause to work together with Dmitry on init system diversity
in Debian. I value his contributions and found him a helpful
collaborator who is pleasant to work with, willing to learn and also
ready to forgive mistakes.
In the early days that nascent team had what can only be described as
poor organisation. We had a considerable amount of accidental
standing on each others' toes, in which we managed to accidentally
entangle Dmitry, who was also trying to help. Dmitry took this in his
stride and joined the team and is now a very valued member.
(Coordination is much improved now, thankfully.)
I haven't investigated the technical situation here, but this thread
was about the process anyway. My inclination is to trust Dmitry's
judgement about when to take steps such as those described here.
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Proposal: Repository for fast-paced package backports
On Tue, Dec 25, 2018 at 11:52:07PM +0100, Dominik George wrote:
> Hi,
>
> >having read the whole Gitlab discussion, I still don't get how/why the
> >new repository depends or relates to backports. Instead it could be
> >self-contained, except for stuff already available in stable. Couldn't
> >you roll the new repository entirely independent of any backports? Even
> >if you say there won't be any additional work for the backport policy
> >owners, letting a new repo depend on backports will implicitly have an
> >impact, which doesn't sound fully thought through yet.
>
> This is answered in the proposal. The reason is to not have volatile
> abused to ease backporting, and to allow packages to easily move back to
> backports again.
Just to make things a bit clearer for people who may not have followed
some of the discussions on d-bp-users lately: the point is to be able to
support fast-moving software with not-so-fast moving dependencies;
the dependencies may easily be backported without too large a burden
(their versions will not come too often, so they will be able to migrate
to testing and thus fulfil the criteria for being in backports), while
the main piece of software moves too fast, including across major
versions and with incompatible changes, so that it is not suitable for
being included in a stable release (thus the part in the proposal about
blocking its migration to testing).
The maintainers of the stack will first package the dependencies, wait
for them to migrate to testing, then backport them, and then they will
upload the main piece of software first to unstable and then to the new
suite under discussion.
G'luck,
Peter
--
Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org} p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
Re: Proposal: Repository for fast-paced package backports
>Just to make things a bit clearer for people who may not have followed >some of the discussions on d-bp-users lately: the point is to be able >to >support fast-moving software with not-so-fast moving dependencies; >the dependencies may easily be backported without too large a burden >(their versions will not come too often, so they will be able to >migrate > to testing and thus fulfil the criteria for being in backports), while >the main piece of software moves too fast, including across major >versions and with incompatible changes, so that it is not suitable for >being included in a stable release (thus the part in the proposal about >blocking its migration to testing). > >The maintainers of the stack will first package the dependencies, wait >for them to migrate to testing, then backport them, and then they will >upload the main piece of software first to unstable and then to the new >suite under discussion. Exactly. And the result shall still have the same quality as any package in -backports, technically, as far as it can. Thus the requirements for version, etc. Volatile is not to become a place to dump packages to bypass -backports. On the contrary. -nik
Re: Proposal: Repository for fast-paced package backports
Hi all, I like the idea of having a volatile archive and I agree with almost all what Dominik wrote about the motivation. I would, however, completely separate it from backports. I.e. - separate NEW queue - different suffix - no need to keep a volatile package out of testing Why? - volatile is a different beast from backports, this should be very clear to both package maintainers and our users - in volatile we can give less guarantees about future upgradability than backport provides - volatile must not put any burden on the backports team, which e.g. a common NEW queue would probably impose Just my 6¢, Cheers
Re: Proposal: Repository for fast-paced package backports
Hi, >I would, however, completely separate it from backports. I.e. > > - separate NEW queue > - different suffix > - no need to keep a volatile package out of testing > >Why? > > - volatile is a different beast from backports, this should be > very clear to both package maintainers and our users The idea is to have them separated, but fully interoperable. I.e. the proposal ensures such things as: - foo is not supportable for the buster release cycle. It goes to volatile. - foo becomes supportable for buster+2. - foo is backported (as in -backports) to buster+1 This will work properly, among other such scenari. > - volatile must not put any burden on the backports team, which > e.g. a common NEW queue would probably impose The whole point is that it is not new work or a new burden. This is one reason for the rules being almost the same and the clear decision path and movement between -backports and -volatile. A -volatile package is handled exactly the same, except it comes from unstable. The workload is the same as if the package had migrated to testing and was being uploaded to -backports. The defined preconditions ensure this is not abused for a ton of packages. -nik
Re: Proposal: Repository for fast-paced package backports
> - no need to keep a volatile package out of testing Oh, and yes. Having a package in testing means it will be supported for a stable lifecycle - a full contradiction to volatile! -nik
Testing init.d script
Hey list, I wasn't sure which other Debian mailing list might be more appropriate, but lsb-discuss appeared to be defunct since 2002. My package has an LSB friendly init.d script it distributes to manage the daemon it ships as a system service. I'd like to use it during unit testing so the daemon can be started, stopped, and various unit tests performed on it between starting and stopping. What is the best practice for this kind of scenario? There are some caveats, of course, because the init.d script cannot be run as root when my project's build environment runs its unit tests. Yours truly, -- Kip Warner | Senior Software Engineer OpenPGP signed/encrypted mail preferred https://www.thevertigo.com signature.asc Description: This is a digitally signed message part
Bug#917320: ITP: ruby-kitchen-docker -- Docker Driver for Test Kitchen
Package: wnpp Severity: wishlist Owner: Mathieu Parent * Package name: ruby-kitchen-docker Version : 2.7.0 Upstream Author : Sean Porter, ... * URL : https://github.com/test-kitchen/kitchen-docker * License : Apache-2.0 Programming Lang: Ruby Description : Docker Driver for Test Kitchen A Docker Driver for Test Kitchen. . Test Kitchen is a test harness tool to execute your configured code on one or more platforms in isolation. A driver plugin architecture is used which lets you run your code on various cloud providers and virtualization technologies such as Amazon EC2, Blue Box, CloudStack, Digital Ocean, Rackspace, OpenStack, Vagrant, Docker, LXC containers, and more. Many testing frameworks are already supported out of the box including Bats, shUnit2, RSpec, Serverspec, with others being created weekly.
Re: Proposal: Repository for fast-paced package backports
On 2018, ഡിസംബർ 26 2:16:07 AM IST, Dominik George wrote: >Heisann, alle sammen, > >as announced in the recent thread about maintaining, I hereby propose a >repository that allows making “backports” of packages available to >users >of the stable distribution, if those packages cannot be maintained in >testing and backported in the usual way. If you are interested in what >lead up to that, please see bug #915050. I will give a short summary of >it here. > > >Reasons for having a special place for some packages > > >(You may want to skip this part if you are familiar with the >situation.) > >As all developers know (but passers-by may not), for software to enter >the Debian archive, it is always uploaded to the unstable distribution, >then migrates to testing (hopefully ;)), which is at some point >snapshot >and made the new stable release. From there on, maintainers have two >obligations: Firstly, keep the package in stable good and secure, e.g. >by uploading security fixes for it once they become available upstream, >or even backport fixes themselves. Secondly, provide the package in >unstable with updates and ensure its migration, to keep it ready for >the >next stable release. > >Now, for some software packages, this process is problematic, because >upstream may have another idea about software lifecycles. Concerning >the >GitLab example, upstream provides security fixes for three months for >their stable releases. Backporting fixes from newer versions is very >hard or impossible because the massive amounts of changes to the >software in every new versions. This is something that also affects >other packages, like Mozilla Firefox, which has a firefox package in >unstable, and a separate firefox-esr package, with the ESR version of >Firefox. Only the latter migrates to testing. > >Users of Debian honour it for its stability, but as an agile software >lifecycle is adapted by more and more very popular software packages, >not being able to install these packages in the trusted, well-known >fashion through the official apt repositories is becoming more and more >of a drawback. > >It can easily be assumed that the normal release and maintenance cycle >of Debian stable will not change, which is very good, so we should find >a way to still provide such software as described above to users. > > >Why backports is not enough >=== > >This also is well-known, but for completeness: Formal backports in >stable-backports are required to be direct backports from testing, and >are a stepping stone within the upgrade from stable to stable+1. Thus, >a >version of a package that is not in testing can never be in >stable-backports. > > >Name of the new repository >== > >In the past, the name “volatile” was used for a similar repository, but >with a different scope (limited to data packages for things like virus >scanners). I will thus use the working title volatile throughout this >proposal, although this may change. > >Other ideas: fastlane, unsupported > >(Please feel free to add other ideas.) > > >Requirements for a package to go into stable-volatile >= > >The new volatile proposal is not intended to ease life for package >maintainers who want to bypass the migration and QA requirements of the >regular stable lifecycle, so special need must be taken to ensure only >packages that need it go into volatile. I want to summarise the >requirements like so: > >- The package must be maintained in unstable, like every other package. > - The package must not be in testing, and care must be taken for the > package not to migrate to testing. > - Regular maintenance for the lifetime of stable must be impossible > or unnecessarily hard, and this requirement should be assessed in > a verifiable manner, e.g. referring to upstream’s lifecycle model. > - There must be notable need for the package. Like for backports, user > requests might be an indicator. > - Should the package be removed from unstable, it must also be removed > from volatile. > - Should the package begin to migrate to testing again, it must > be moved to stable-backports. > >Before starting to maintain a volatile package, the maintainer shall >seek consent (or doubt) on debian-devel. > > >Building packages and package dependencies >== > >Packages for volatile are built the same way as formal backports, only >that the source is taken from unstable rather than testing. In >particular: > > - Changes shall be kept as small as possible. > - The package is rebuilt against stable. >- The package may depend on packages in stable, stable-backports or >stable-volatile. > >Dependencies on other packages in volatile should be avoided if >possible. Especially, dependencies of the package that also need >backporting must not be added to volatile just because they are >dependencies —
