Re: Bug#915407: libpam-systemd: please add a virtual package "logind" to allow alternatives
]] Felipe Sateler Two minor typos. > The proposed virtual packages are: > > logind: a org.freedesktop.login1 D-Bus API implementation «an org…» > default-logind: should be provided by the distributions default logind > provider (currently pam-systemd) distribution's. Otherwise, this looks like a good idea to me. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Bug#917337: ITP: slirp4netns -- User-mode networking for unprivileged network namespaces
Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler
Package name: slirp4netns
Version : git HEAD
Upstream Author : Akihiro Suda
URL : https://github.com/rootless-containers/slirp4netns
License : GPLv2+
Programming Lang: C
Description : User-mode networking for unprivileged network namespaces
slirp4netns provides user-mode networking for unprivileged network
namespaces.
.
slirp4netns allows connecting a network namespace to the Internet in a
completely unprivileged way, by connecting a TAP device in a network
namespace to the usermode TCP/IP stack ("slirp").
This is a dependency of buildah and podman, which I am looking at for packaging
right now as well.
I'd appreciate suggestions for what team would be appropriate to maintain this
group of packages. Unless better suggestions come up, I intend to maintain it
on salsa.debian.org in the "Debian" group
(cf.
https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group).
More information as taken from
https://github.com/rootless-containers/slirp4netns/blob/master/README.md:
Motivation
Starting with Linux 3.8, unprivileged users can create network_namespaces(7)
along with user_namespaces(7). However, unprivileged network namespaces had not
been very useful, because creating veth(4) pairs across the host and network
namespaces still requires the root privileges. (i.e. No internet connection)
slirp4netns allows connecting a network namespace to the Internet in a
completely unprivileged way, by connecting a TAP device in a network namespace
to the usermode TCP/IP stack ("slirp").
Projects using slirp4netns:
- Usernetes (via RootlessKit)
- Podman
- Buildah
- ctnr (via slirp-cni-plugin)
- RootlessKit
- become-root
- slirp-cni-plugin
Re: Testing init.d script
On Tue, Dec 25, 2018 at 08:52:19PM -0800, Kip Warner wrote: > 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. Unit tests can normally use some kind of temporary test harness instead of the full-blown init script, and that's usually the best first line of defence since it's typically simpler and faster. Of course it's also worth testing the init script itself, or other behaviours of the package when it's in its installed state rather than just running out of the build tree. For that purpose, have you considered autopkgtest (https://ci.debian.net/doc/)? A test with the "needs-root" restriction can start and stop services. -- Colin Watson [cjwat...@debian.org]
Re: Proposal: Repository for fast-paced package backports
On Wed, Dec 26, 2018 at 12:07:42AM +0100, Dominik George wrote: > I actually think volatile is a good name. After all, it's not so far from the > previous volatile. volatile is a very bad name for this because we've used it already for something else. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Proposal: Repository for fast-paced package backports
>> I actually think volatile is a good name. After all, it's not so far >from the previous volatile. > >volatile is a very bad name for this because we've used it already for >something else. Well, I consider it more or less the same basic idea. The old and new ideas have more in common than not, with the only difference being that previously, volatile packages also had versions in stable. -nik
Re: Proposal: Repository for fast-paced package backports
On Wed, Dec 26, 2018 at 01:04:44PM +0530, Pirate Praveen wrote: > If it has to be completely separate from -backports, it means some packages > will need to be maintained twice, even when they meet the criteria for > backports fully, just because a package in volatile declare a dependency on > them. There is nothing that stops you, or whoever wants to maintain this newn repository from doing it in a way that 1) reuses what's already in backports, even automatically and 2) adds the bits that are not deemed appropriate for backports. signature.asc Description: PGP signature
Re: Proposal: Repository for fast-paced package backports
On Wed, 26 Dec 2018 13:07:07 +, Holger Levsen wrote: (Can we keep this on one mailing list, please? /me restricts this to -devel) > On Wed, Dec 26, 2018 at 12:07:42AM +0100, Dominik George wrote: > > I actually think volatile is a good name. After all, it's not so far from > > the previous volatile. > volatile is a very bad name for this because we've used it already for > something else. Agreed. And besides that, I think the more universal answer is bikesheds/PPAs/you-name-it instead of yet-another-suite. IIRC, there's even a draft specification … What I found now is https://lists.debian.org/debian-devel/2013/05/msg00131.html [0] https://lists.debian.org/debian-dak/2015/09/msg00023.html ff. Since then bikesheds keep being mentioned every now and then for handling fast-moving software; e.g. https://lists.debian.org/debian-devel/2016/01/msg00696.html https://lists.debian.org/debian-devel/2016/03/msg00363.html https://lists.debian.org/debian-devel/2016/04/msg00059.html https://lists.debian.org/debian-devel/2018/10/msg00072.html Cheers, gregor [0] "Aggressive Backport: This is the "dotdeb.org" scenario. For whatever reason, people need whatever the latest version of php/mysql/apache/nginx/selectyourpoison is, compiled for (old)stable, in order to run on their otherwise stable servers." -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Rolling Stones: Moonlight-mile-live signature.asc Description: Digital Signature
Re: Proposal: Repository for fast-paced package backports
On 2018-12-26 15:05, gregor herrmann wrote: > (Can we keep this on one mailing list, please? /me restricts this to > -devel) Agreed. > And besides that, I think the more universal answer is > bikesheds/PPAs/you-name-it instead of yet-another-suite. IMHO, this is not the same. Both "volatile/fastlane/whatever" and "PPAs/bikeshed" have legitimate use cases.
Re: Proposal: Repository for fast-paced package backports
[As requested, keeping it to -devel only] On 12/26/18 7:35 PM, Antonio Terceiro wrote: > On Wed, Dec 26, 2018 at 01:04:44PM +0530, Pirate Praveen wrote: >> If it has to be completely separate from -backports, it means some packages >> will need to be maintained twice, even when they meet the criteria for >> backports fully, just because a package in volatile declare a dependency on >> them. > > There is nothing that stops you, or whoever wants to maintain this newn > repository from doing it in a way that 1) reuses what's already in > backports, even automatically and 2) adds the bits that are not deemed > appropriate for backports. > The -backports team does not want the dependencies of gitlab to be in -backports even though it meets the criteria for backports. So we will end up adding it to volatile. Now if some one else wants the same in -backports, they will have to repeat the process. Take nodejs or npm for example, which I backported now. In buster the -backports team does not want it in backports if I'm doing it for gitlab, even though they satisfy the requirement for -backports. So we will end up uploading these to volatile, if someone else wants it in -backports, they will have to do it again. It is one way (volatile can use -backports, but -backports can't use volatile). I'm fine with that if people don't want our work for volatile not added to -backports. Dominik, I think we can go ahead with volatile as separate suite and take packages from -backports if exist but add all new dependencies to -volatile. This, "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 backport. Obviously, the unprobable edge case occurs when the package depends on another package that also fully qualifies for volatile, as described above." should be changed to, "Dependencies of the package that also need backporting must be added to volatile." signature.asc Description: OpenPGP digital signature
Re: Proposal: Repository for fast-paced package backports
On Wed, Dec 26, 2018 at 02:35:19PM +0100, Dominik George wrote: > >volatile is a very bad name for this because we've used it already for > >something else. > Well, I consider it more or less the same basic idea. The old and new ideas > have more in common than not, with the only difference being that previously, > volatile packages also had versions in stable. that *you* understand this naming was out of the question and is besides my point. (and this is absolutly not ment in any hostile way, just stating a fact.) -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Proposal: Repository for fast-paced package backports
On Wed, 26 Dec 2018, Pirate Praveen wrote: > > > 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 o
Re: Proposal: Repository for fast-paced package backports
Hi, On Wed, Dec 26, 2018 at 03:05:55PM +0100, gregor herrmann wrote: > (Can we keep this on one mailing list, please? /me restricts this to > -devel) No. This has the potential of keeping people who are directly impacted by this proposal out of the loop. > And besides that, I think the more universal answer is > bikesheds/PPAs/you-name-it instead of yet-another-suite. Absolutely not. It might be an answer, but to an entirely different question. This proposal is about providing packages under the same rules, policies and QA as any other package in Debian, built in the same trustworthy manner. This is something a PPA does not do. To stay with the gitlab example: I would very much like to see some people (including the company I work at, two organisations I am otherwise involved with,…) use packages from Debian. This is mostly about trust - it is a very useful policy to limit the entities to trust for software distribution if you run production systems, especially when they handle third-party data. Debian is such an entity - while there are many people working in it, it is a body with defined procedures and standards that can be relied upon. Debian telling users to add a PPA to their trusted entities that is managed by some person alone, be they a DD or not, defeats this entirely. On Wed, Dec 26, 2018 at 08:29:17PM +0530, Pirate Praveen wrote: > The -backports team does not want the dependencies of gitlab to be in > -backports even though it meets the criteria for backports. So we will > end up adding it to volatile. Now if some one else wants the same in > -backports, they will have to repeat the process. > > Take nodejs or npm for example, which I backported now. In buster the > -backports team does not want it in backports if I'm doing it for > gitlab, even though they satisfy the requirement for -backports. So we > will end up uploading these to volatile, if someone else wants it in > -backports, they will have to do it again. > > It is one way (volatile can use -backports, but -backports can't use > volatile). I'm fine with that if people don't want our work for volatile > not added to -backports. > > Dominik, > > I think we can go ahead with volatile as separate suite and take > packages from -backports if exist but add all new dependencies to -volatile. > > This, > > "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 backport. Obviously, > the unprobable edge case occurs when the package depends on another > package that also fully qualifies for volatile, as described above." > > should be changed to, > > "Dependencies of the package that also need backporting must be added to > volatile." No. The dpendencies of gitlab not being accepted into backports right now is an entirely different issue. I am repeating myself: This proposal is not intended to ease the life of maintainers whose packages qulify for -backports. The only difference between -backports and -volatile in this draft proposal is that -volatile can take packages that are not in testing due to the exact one reason that hey have a shorter lifespan. No single other thing qualifies a package for -volatile if it is not qualified for -backports. If there are other issues to solve than the lifespan of the package version, they must be solved in another way. On Wed, Dec 26, 2018 at 04:32:28PM +0100, Alexander Wirt wrote: > As I said, gitlab was not about manpower. This new repo is completly against > our vision of what backports is. Therefore we don't want it within the > backports suite. Alexander, please don't get me wrong, but have you read the full proposal by now and considered it, independent of the gitlab story? I am pretty certain you did not did that yesterday before starting to object it - not because of your argumentation, but because reading, understanding, considering and challenging it and then writing your reply is simply not physically possible within the 4½ minutes it took you to object to it ☺. Therefore, I ask you to bring up the points you think are against your vision of backports. In fact, the proposal is laid out in a way that explicitly does *not* contradict it, and I am wondering what makes you think it does, let alone "completely". I still got the impression you are also confusing me with Praveen, to the views of whom I do bject as well to some extent (see above). So, this proposal is about extending -backports, but without getting in its way, and following all its ideas except for the source suite. Thus, please let us discuss this in a well-founded, argumentative manner instead of just ruling it out from the start. Thanks, Nik signature.asc Description: PGP sign
Bug#917366: RFP: postfix-mta-sts-resolver -- daemon that adds support for MTA-STS to postfix
Package: wnpp Severity: wishlist * Package name: postfix-mta-sts-resolver Version : 0.2.4 * URL : https://github.com/Snawoot/postfix-mta-sts-resolver * License : MIT Programming Lang: python Description : Daemon which provides TLS client policy for Postfix via socketmap, according to domain MTA-STS policy.
Re: Proposal: Repository for fast-paced package backports
On Wed, 26 Dec 2018, Dominik George wrote: > Hi, > > On Wed, Dec 26, 2018 at 03:05:55PM +0100, gregor herrmann wrote: > > (Can we keep this on one mailing list, please? /me restricts this to > > -devel) > > No. This has the potential of keeping people who are directly impacted > by this proposal out of the loop. > > > And besides that, I think the more universal answer is > > bikesheds/PPAs/you-name-it instead of yet-another-suite. > > Absolutely not. It might be an answer, but to an entirely different > question. This proposal is about providing packages under the same > rules, policies and QA as any other package in Debian, built in the same > trustworthy manner. This is something a PPA does not do. > > To stay with the gitlab example: I would very much like to see some > people (including the company I work at, two organisations I am > otherwise involved with,…) use packages from Debian. This is mostly > about trust - it is a very useful policy to limit the entities to trust > for software distribution if you run production systems, especially when > they handle third-party data. Debian is such an entity - while there are > many people working in it, it is a body with defined procedures and > standards that can be relied upon. Debian telling users to add a PPA to > their trusted entities that is managed by some person alone, be they a > DD or not, defeats this entirely. > > On Wed, Dec 26, 2018 at 08:29:17PM +0530, Pirate Praveen wrote: > > The -backports team does not want the dependencies of gitlab to be in > > -backports even though it meets the criteria for backports. So we will > > end up adding it to volatile. Now if some one else wants the same in > > -backports, they will have to repeat the process. > > > > Take nodejs or npm for example, which I backported now. In buster the > > -backports team does not want it in backports if I'm doing it for > > gitlab, even though they satisfy the requirement for -backports. So we > > will end up uploading these to volatile, if someone else wants it in > > -backports, they will have to do it again. > > > > It is one way (volatile can use -backports, but -backports can't use > > volatile). I'm fine with that if people don't want our work for volatile > > not added to -backports. > > > > Dominik, > > > > I think we can go ahead with volatile as separate suite and take > > packages from -backports if exist but add all new dependencies to -volatile. > > > > This, > > > > "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 backport. Obviously, > > the unprobable edge case occurs when the package depends on another > > package that also fully qualifies for volatile, as described above." > > > > should be changed to, > > > > "Dependencies of the package that also need backporting must be added to > > volatile." > > No. The dpendencies of gitlab not being accepted into backports right > now is an entirely different issue. I am repeating myself: This proposal > is not intended to ease the life of maintainers whose packages qulify > for -backports. The only difference between -backports and -volatile in > this draft proposal is that -volatile can take packages that are not in > testing due to the exact one reason that hey have a shorter lifespan. No > single other thing qualifies a package for -volatile if it is not > qualified for -backports. And this is also solved. I emptied the NEW queue two or three days ago. If there are dependencies missing the backports wasn't tested, which sucks. > If there are other issues to solve than the lifespan of the package > version, they must be solved in another way. > > On Wed, Dec 26, 2018 at 04:32:28PM +0100, Alexander Wirt wrote: > > As I said, gitlab was not about manpower. This new repo is completly against > > our vision of what backports is. Therefore we don't want it within the > > backports suite. > > Alexander, please don't get me wrong, but have you read the full > proposal by now and considered it, independent of the gitlab story? I am > pretty certain you did not did that yesterday before starting to object > it - not because of your argumentation, but because reading, > understanding, considering and challenging it and then writing your > reply is simply not physically possible within the 4½ minutes it took > you to object to it ☺. Yes. Nothing changed til then. > Therefore, I ask you to bring up the points you think are against your > vision of backports. In fact, the proposal is laid out in a way that > explicitly does *not* contradict it, and I am wondering what makes you > think it does, let alone "completely". > > I still got the impression you
Re: Proposal: Repository for fast-paced package backports
> I don't want backports to contain things are are not suited for a > release. That's why we are doing all this. It is NOT about anything to backports. It is about adding something new that uses the same RULES as backports, with a slight diversion, and thus can also make use of infrastructure already there for backports. Neither being economic with manpower and machines nor trying to be a good neighbour by adhering to the same rules means to change or add anything to -backports. -nik signature.asc Description: PGP signature
Re: Proposal: Repository for fast-paced package backports
On Wed, 26 Dec 2018, Dominik George wrote: > > I don't want backports to contain things are are not suited for a > > release. > > That's why we are doing all this. It is NOT about anything to backports. > It is about adding something new that uses the same RULES as backports, > with a slight diversion, and thus can also make use of infrastructure > already there for backports. Neither being economic with manpower and > machines nor trying to be a good neighbour by adhering to the same rules > means to change or add anything to -backports. And I said I think it should start independently to prove its worth the work. And it isn't backports infrastructure. It is ftpmaster's, we are just users. We can't even add anything, even if we want to. The only things we control are the NEW queue of the backports-suites ( a new suite with have its own queue) and the website (which also doesn't fit for the new suite). So imho addressing this as a backports topic is just wrong. Alex signature.asc Description: PGP signature
Re: Proposal: Repository for fast-paced package backports
On 2018, ഡിസംബർ 26 10:15:35 PM IST, Dominik George wrote: >No. The dpendencies of gitlab not being accepted into backports right >now is an entirely different issue. I am repeating myself: This >proposal >is not intended to ease the life of maintainers whose packages qulify >for -backports. The only difference between -backports and -volatile in >this draft proposal is that -volatile can take packages that are not in >testing due to the exact one reason that hey have a shorter lifespan. >No >single other thing qualifies a package for -volatile if it is not >qualified for -backports. > >If there are other issues to solve than the lifespan of the package >version, they must be solved in another way. I agree with you, it is the best outcome. But when people with power (-backports ftp masters) are not willing to consider it, we have to go with plan B, which is less than ideal, but can move things forward. >On Wed, Dec 26, 2018 at 04:32:28PM +0100, Alexander Wirt wrote: >> As I said, gitlab was not about manpower. This new repo is completly >against >> our vision of what backports is. Therefore we don't want it within >the >> backports suite. > If people argue both ways, how can we answer? Either it adds more work for -backports team or it does not. Some people say its not fair to add more load while ftp masters say its not about load. If it does not add extra load, then I don't see why it can be kept out of -backports when it qualifies except for being a dependency of -volatile. They say it does not match with their vision. So what option is left for us? We have to take their word for it and move forward without inconveniencing them. I don't think -backports ftp masters is going to accept this proposal (from the responses we already received), so I can live with all dependencies in -volatile. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Proposal: Repository for fast-paced package backports
> >If there are other issues to solve than the lifespan of the package > >version, they must be solved in another way. > > I agree with you, it is the best outcome. But when people with power > (-backports ftp masters) are not willing to consider it, we have to go > with plan B, which is less than ideal, but can move things forward. Plan B in this case are PPAs. If you want to engage in that idea, please do separately from the -volatile idea. > >> As I said, gitlab was not about manpower. This new repo is completly > >against > >> our vision of what backports is. Therefore we don't want it within > >the > >> backports suite. > > > If people argue both ways, how can we answer? Either it adds more work > for -backports team or it does not. Some people say its not fair to > add more load while ftp masters say its not about load. As Alex laid out, it's mostly just the -backports team handling the NEW queue. So all of this really is independent from -backports, if another NEW queue is added (which I do not think is the best idea, but still possible). But, I do not think it is possible to start -volatile completely independently. I am pretty certain there is enough man power to handle it as a new suite, but on the other hand I am also certain there is not enough manpower to operate a compelte set of seperate services for it. In any case, I propose we stop discussing the who and where questions for a while and concentrate on the what and how. I will collect the opinions on that, and in a week or two, incorporate them into the proposal, along with the different possibilities for implementation. -nik signature.asc Description: PGP signature
Re: Proposal: Repository for fast-paced package backports
On Wed, 26 Dec 2018, Pirate Praveen wrote: > > > On 2018, ഡിസംബർ 26 10:15:35 PM IST, Dominik George > wrote: > >No. The dpendencies of gitlab not being accepted into backports right > >now is an entirely different issue. I am repeating myself: This > >proposal > >is not intended to ease the life of maintainers whose packages qulify > >for -backports. The only difference between -backports and -volatile in > >this draft proposal is that -volatile can take packages that are not in > >testing due to the exact one reason that hey have a shorter lifespan. > >No > >single other thing qualifies a package for -volatile if it is not > >qualified for -backports. > > > >If there are other issues to solve than the lifespan of the package > >version, they must be solved in another way. > > I agree with you, it is the best outcome. But when people with power > (-backports ftp masters) are not willing to consider it, we have to go with > plan B, which is less than ideal, but can move things forward. > > >On Wed, Dec 26, 2018 at 04:32:28PM +0100, Alexander Wirt wrote: > >> As I said, gitlab was not about manpower. This new repo is completly > >against > >> our vision of what backports is. Therefore we don't want it within > >the > >> backports suite. > > > > If people argue both ways, how can we answer? Either it adds more work for > -backports team or it does not. Some people say its not fair to add more load > while ftp masters say its not about load. > > If it does not add extra load, then I don't see why it can be kept out of > -backports when it qualifies except for being a dependency of -volatile. They > say it does not match with their vision. So what option is left for us? We > have to take their word for it and move forward without inconveniencing them. > I don't think -backports ftp masters is going to accept this proposal (from > the responses we already received), so I can live with all dependencies in > -volatile. Jftr, we never said anything about dependencies. If it qualifies for backports, I don't see any reason for not having those deps in backports. We never questioned that topic. If it qualifies: great. If not, please don't upload it. A package qualifies for backports if: - it adds new features - wasn't available before - is in testing - will receive support for the lifetime of the backports suite so things like npm are perfectly fine for backports. And we never said anything for libs, even if they are "standalone" (nothing in backports is using those libs). The main problem with gitlab was: from our perspective several hundred packages only had one uploader (to backports, other suites don't count) and we wanted to minimize the risk of being alone with hundreds of unmaintained backports. We solved that problem (by getting more people responsible for the backports) and accepted it. Alex
Re: Proposal: Repository for fast-paced package backports
Hi, Pirate Praveen wrote: > I agree with you, it is the best outcome. But when people with power > (-backports ftp masters) are not willing to consider it, we have to > go with plan B, which is less than ideal, but can move things > forward. Just to avoid this being thought of as an idiosyncrasy of backports ftpmasters, I suppose I should put my own views forward. 1. Nik, I think you're onto something with this fastpaced proposal. I would be happy to see some suite to make it easier for users to consume packages that lack long-term support, like non-ESR firefox. 2. I am happy with the current charter of backports and I think it's possible to move forward with fastpaced without having to change that charter. 3. formerer is speaking from experience when he says that it's possible to make this kind of change unofficially first, learn from it, and thus set the groundwork for making it official. If you foresee obstacles to that, can you say more about where they lie? Maybe we can help address them, or maybe we can find another way forward. If you don't see obstacles, why not start today? 4. Just to reiterate about (2), just like I think it's completely reasonable for release team to exercise discretion about what goes in stable and testing, it's completely reasonable for backports team to exercise discretion about what goes into backports. Please don't take it personally. It's an important part of what they do to make the suite sustainable, and I am very grateful for it. Thanks and hope that helps, Jonathan
Re: Proposal: Repository for fast-paced package backports
On Wed, 26 Dec 2018, Dominik George wrote: > > >If there are other issues to solve than the lifespan of the package > > >version, they must be solved in another way. > > > > I agree with you, it is the best outcome. But when people with power > > (-backports ftp masters) are not willing to consider it, we have to go > > with plan B, which is less than ideal, but can move things forward. > > Plan B in this case are PPAs. If you want to engage in that idea, please > do separately from the -volatile idea. > > > >> As I said, gitlab was not about manpower. This new repo is completly > > >against > > >> our vision of what backports is. Therefore we don't want it within > > >the > > >> backports suite. > > > > > > If people argue both ways, how can we answer? Either it adds more work > > for -backports team or it does not. Some people say its not fair to > > add more load while ftp masters say its not about load. > > As Alex laid out, it's mostly just the -backports team handling the NEW > queue. So all of this really is independent from -backports, if another > NEW queue is added (which I do not think is the best idea, but still > possible). > > But, I do not think it is possible to start -volatile completely > independently. I am pretty certain there is enough man power to handle > it as a new suite, but on the other hand I am also certain there is not > enough manpower to operate a compelte set of seperate services for it. as said, we are also guests on the ftpmaster services. They are the people to ask. The NEW queue is just a minor detail of a suite. Alex signature.asc Description: PGP signature
Re: Proposal: Repository for fast-paced package backports
On 25/12/2018 21:46, Dominik George wrote: 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. So what would a user of testing do? Will there be a $codename-volatile[1] suite for testing users? Or would they directly install unstable with no other pre-release staging ground? (Which seems like a bad idea.) Similarly what are the constraints you set for upgrading, if any? How far back will upgrades work and how current do users need to keep their system in order to still be able to upgrade? For one, I think you will need to set expectations here towards the maintainers if a package is never included in a stable release, as they get very muddy otherwise. Plus you need to set expectations for the users as the next package (maybe not gitlab) might come up with requirements that upgrades need to go through every version on the way to, say, update the database properly. And that's hardly supportable unless everyone knows to update quickly. Kind regards Philipp Kern [1] I would like to re-register my objection to that name for the same reason Holger stated: it is confusing to reuse an older name (which, by the way, started outside of Debian, too and was then merged in) with a new concept.
Re: Proposal: Repository for fast-paced package backports
Hi,
> 2. I am happy with the current charter of backports and I think it's
> possible to move forward with fastpaced without having to change
> that charter.
Yep. That's exactly why the proposal changes nothing about -backports. I
am still confused why Alex and you keep insisting that anything would be
changing there.
> 3. formerer is speaking from experience when he says that it's
> possible to make this kind of change unofficially first, learn
> from it, and thus set the groundwork for making it official.
>
> If you foresee obstacles to that, can you say more about where
> they lie? Maybe we can help address them, or maybe we can find
> another way forward.
>
> If you don't see obstacles, why not start today?
I think I already made those obstacles clear: Starting outside means
buying, installing and operating at least a server vor
volatile.debian.net (or whatever you call it), setting up and
maintaining an upload queue, the queued, and everything around it,
building from source for at least the most important architectures on
hardware that needs to be there and maintained for that, etc. There are
several issues with that:
- It costs a lot time that could better be used elsewhere.
- It costs extra money, which I for one do not have to spare.
- I do not sure I can do it right, because I do not know all the
technical details.
Thus, because the change as it is proposed has such a low impact on
anything else, I consider doing all that over again unnecessary.
Don't get me wrong - I would not hesitate to go through it if it were
for anything that could break things, or make life harder for others, or
something like that. I am just putting the impact of the change and the
resources needed for seperate infrastructure in relation. Everything
about this proposal ahs already been tested when -backports was young
(thanks for doing the work!). This proposal contains nothing new to
learn, neither technically nor policy-wise. It works the same way
backports do, with the same considerations, except for the source and
target suites of the packages.
If you know how to start with a new service at
{volatile,fastpaced,whatever}.debian.net without having to reinvent the
wheel for acceptign uploads, getting packages built, etc., please
enlighten me.
-nik
signature.asc
Description: PGP signature
Re: Proposal: Repository for fast-paced package backports
Dominik George wrote:
> Jonathan Nieder wrote:
>> 2. I am happy with the current charter of backports and I think it's
>> possible to move forward with fastpaced without having to change
>> that charter.
>
> Yep. That's exactly why the proposal changes nothing about -backports. I
> am still confused why Alex and you keep insisting that anything would be
> changing there.
It has a few points of intersection:
- Should the package begin to migrate to testing again, it must
be moved to stable-backports.
- Using the same ~bpo version namespace
- "treat it as part of backports", which I assume means that
backports users would automatically consume this repo
- new binary uploads to volatile have to undergo the
same NEW queue as backports
I don't think these are deep, inherent things (it's possible to
preserve the spirit of the proposal while removing them), but please
don't accuse me of pulling them out of thin air.
[...]
>> 3. formerer is speaking from experience when he says that it's
>> possible to make this kind of change unofficially first, learn
>> from it, and thus set the groundwork for making it official.
>>
>> If you foresee obstacles to that, can you say more about where
>> they lie? Maybe we can help address them, or maybe we can find
>> another way forward.
>>
>> If you don't see obstacles, why not start today?
>
> I think I already made those obstacles clear: Starting outside means
> buying, installing and operating at least a server vor
> volatile.debian.net (or whatever you call it), setting up and
> maintaining an upload queue, the queued, and everything around it,
> building from source for at least the most important architectures on
> hardware that needs to be there and maintained for that, etc.
Thanks. That points to who you may want to get help from:
- DSA, for hosting
- ftpmasters, in case you'd share their DAK instance
- porters, to find out what level of port + buildd support they want
to maintain
[...]
> - I do not sure I can do it right, because I do not know all the
>technical details.
That's fine. There's no time like the present to learn!
> Thus, because the change as it is proposed has such a low impact on
> anything else, I consider doing all that over again unnecessary.
>
> Don't get me wrong - I would not hesitate to go through it if it were
> for anything that could break things, or make life harder for others, or
> something like that.
I think you're underestimating the impact on other teams. That's
fine: it's probably worth it, but you will need to get buy in.
[...]
> If you know how to start with a new service at
> {volatile,fastpaced,whatever}.debian.net without having to reinvent the
> wheel for acceptign uploads, getting packages built, etc., please
> enlighten me.
backports maintainers, debian-ports maintainers, and others may have
experience with this. I don't know the best place to get advice from
them --- you may already be in the right place. :)
Sincerely,
Jonathan
Re: Proposal: Repository for fast-paced package backports
> > - The package must not be in testing, and care must be taken for the > > package not to migrate to testing. > So what would a user of testing do? Will there be a $codename-volatile[1] > suite for testing users? Or would they directly install unstable with no > other pre-release staging ground? (Which seems like a bad idea.) The testing distribution and this concept contradict each other. The testing distribution is the least supported stage in the Debian release cycle, and if used, shall only be used for testing the next Debian release. Especially, there are no timely security updates in testing, neither by the security nor by the maintainer. So using it for anything other than testing the next Debian release in a laboratory is a bad idea. This proposal, however, is about providing fast-paced software as an exception on an otherwise stable system. So if anyone wants to test fast-paced software within a Debian testing system, they should use the package from unstable, yes. (Having testing on a system without the sid zources is close to impossible outside the freeze anyway.) > > Similarly what are the constraints you set for upgrading, if any? How far > back will upgrades work and how current do users need to keep their system > in order to still be able to upgrade? For one, I think you will need to set > expectations here towards the maintainers if a package is never included in > a stable release, as they get very muddy otherwise. Plus you need to set > expectations for the users as the next package (maybe not gitlab) might come > up with requirements that upgrades need to go through every version on the > way to, say, update the database properly. And that's hardly supportable > unless everyone knows to update quickly. That certainly is something maintainers need to care about. (I consider a software not supporting skipping versions on upgrade a bug, anyway.) But most importantly, this is nothing that is specific to the -volatile proposal - it is the same for regular backports. So discussing this general backporting issue should not be mixed with the discussion of this proposal. -nik signature.asc Description: PGP signature
Re: Proposal: Repository for fast-paced package backports
> - Should the package begin to migrate to testing again, it must >be moved to stable-backports. > > - Using the same ~bpo version namespace Both of these poitns are there to *not* change anything about backports. If a package stops qualifying for -volatile, and starts qualifying for -backports, it's under the backports realm again. I consider this very important so it is very clear for maintainers what -volatile is for - in particular, *not* for bypassing -backports limitations. The sharing of the version namespace is partially a direct consequence of the previous point. > - "treat it as part of backports", which I assume means that >backports users would automatically consume this repo No. I see where the misunderstanding comes from - that's not what I was intending to say. -colatile is intended to be a compelte separate suite, that users can add to their sources.list separately (if they do, they also need to add the regular -backports, however). The rest of what I meant as "treat as part of" is adhering to the same rules, standards, etc., and re-using existing infrastructure like the NEW queue due to that. Also to ensure that the qualification of packages for either -backports or -volatile is clear and inforced. > > - new binary uploads to volatile have to undergo the >same NEW queue as backports This as about sharing resources and enforcing the same rules (except for source and target suites). The proposal is still possible without sharing the same NEW queue, but the first two points are a major concept ensuring that it will work. It will not work as well when removing them. -nik signature.asc Description: PGP signature
Re: Proposal: Repository for fast-paced package backports
On 26/12/2018 19:31, Dominik George wrote: - The package must not be in testing, and care must be taken for the package not to migrate to testing. So what would a user of testing do? Will there be a $codename-volatile[1] suite for testing users? Or would they directly install unstable with no other pre-release staging ground? (Which seems like a bad idea.) The testing distribution and this concept contradict each other. The testing distribution is the least supported stage in the Debian release cycle, and if used, shall only be used for testing the next Debian release. Especially, there are no timely security updates in testing, neither by the security nor by the maintainer. So using it for anything other than testing the next Debian release in a laboratory is a bad idea. This proposal, however, is about providing fast-paced software as an exception on an otherwise stable system. So if anyone wants to test fast-paced software within a Debian testing system, they should use the package from unstable, yes. (Having testing on a system without the sid zources is close to impossible outside the freeze anyway.) Of course you can use testing without having sid available, that's the point of testing[1]. I think there's a misunderstand about testing lurking here, too. And the requirement of backports for the package to be in testing is also to get a sane upgrade path from stable to next-stable. So you have to support your thing alongside testing, too. At least during the freeze, but optimally shortly after the release has been cut. Similarly what are the constraints you set for upgrading, if any? How far back will upgrades work and how current do users need to keep their system in order to still be able to upgrade? For one, I think you will need to set expectations here towards the maintainers if a package is never included in a stable release, as they get very muddy otherwise. Plus you need to set expectations for the users as the next package (maybe not gitlab) might come up with requirements that upgrades need to go through every version on the way to, say, update the database properly. And that's hardly supportable unless everyone knows to update quickly. That certainly is something maintainers need to care about. (I consider a software not supporting skipping versions on upgrade a bug, anyway.) But most importantly, this is nothing that is specific to the -volatile proposal - it is the same for regular backports. So discussing this general backporting issue should not be mixed with the discussion of this proposal. For backports the general supportability assumption is that you provide a sane upgrade path from stable to the backports and from the backport to the next stable (optimally the same package). Once you take the presence of the stable package out of the mix, it becomes weird. How long do you need to preserve compatibility code? How does an agile package that does not fit Debian's release cycle cater to these requirements? Just discounting that on the grounds of "that's normal for backporting" if it's unique to your proposal is not quite satisfactory to me. Kind regards Philipp Kern [1] You can make the argument that there's a problem with security update. But that's why the urgency system exists and maintainers can declare that a certain package needs to migrate with minimal waiting time. And most of the time (not always) the exploits start to materialize later.
Re: Proposal: Repository for fast-paced package backports
> For backports the general supportability assumption is that you provide a > sane upgrade path from stable to the backports and from the backport to the > next stable (optimally the same package). Once you take the presence of the > stable package out of the mix, it becomes weird. How long do you need to > preserve compatibility code? How does an agile package that does not fit > Debian's release cycle cater to these requirements? This is wrong, at least in a big part. The stable release cycle does not apply for -backports. A package in -backports can be udpated an arbitrary number of times during the development window of stable+1, leaving us with the exact same issue as you are describing for -volatile. If you take into account edge cases, where a package is removed from testing during the freeze, is removed from -backports as a result, is not released with stable+1, then gets fixed and reintroduced to testing and -backports, it gets even closer. In short: This is a situation every maintainer has to take measures for, be it in -backports or -volatile. -nik signature.asc Description: PGP signature
Re: Bug#915407: libpam-systemd: please add a virtual package "logind" to allow alternatives
Hello, On Mon 24 Dec 2018 at 05:37pm -0300, Felipe Sateler wrote: > 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 > > 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. > > Adam/other elogind maintainers, please clarify/improve wording if this was > somehow inaccurate. There seems to be a consensus (and this is not really controversial), to please file a bug against Policy with a patch to the virtual package list for seconding. -- Sean Whitton signature.asc Description: PGP signature
Re: Proposal: Repository for fast-paced package backports
Hi, > How to handle upgrades from stable to stable+1. Packages from backports > upgrade with no issues as stable+1 contains the same packages already > compiled for the stable+1. As long as the package is in -volatile, it is not in stable+1, and upgrades are ensured by the volatile maintainer. If the package is to go into stable+1 again, ist must move to -backports (see original proposal for details on that). > How about LTS? As stable-rolling repository would be usable in > conjunction with stable-backports and stable, would then > oldstable-rolling continue to roll or just freeze in place at the moment > when the stable becomes oldstable? I think oldstable-volatile could keep rolling if the maintainer wishes to do so, but must never be newer than stable-volatile, of course. Upgrades between oldstable-volatile and stable-volatile must be ensured by the maintainer. > Continuous delivery development model based upstream applications are > not quite a good fit for a stable release distribution. Maybe that's why we are drafting a mechanism to support them outside the stable release distribution ;). -nik signature.asc Description: PGP signature
Re: Proposal: Repository for fast-paced package backports
On 12/25/18 3:46 PM, Dominik George wrote: [...] > > 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 > "rolling" sounds like a good fit [...] > > 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. > stable-rolling sounds more appropriate than stable-volatile. > Dependencies on other packages in volatile should be avoided if > possible. How to handle upgrades from stable to stable+1. Packages from backports upgrade with no issues as stable+1 contains the same packages already compiled for the stable+1. How about LTS? As stable-rolling repository would be usable in conjunction with stable-backports and stable, would then oldstable-rolling continue to roll or just freeze in place at the moment when the stable becomes oldstable? [...] > > > Implications for the situation at hand (gitlab) > === > > As there were quite a few concerns raised (some of which I share, and > some I don’t): Of course, if a software intended for volatile has a ton > of dependencies (intended to go into backports), all backports rules and > powers of the ftp-masters apply. Repeating myself: volatile is not meant > to ease the life of maintainers. > Continuous delivery development model based upstream applications are not quite a good fit for a stable release distribution. Milan signature.asc Description: OpenPGP digital signature
Re: Testing init.d script
On Wed, 2018-12-26 at 12:09 +, Colin Watson wrote: > Unit tests can normally use some kind of temporary test harness > instead of the full-blown init script, and that's usually the best > first line of defence since it's typically simpler and faster. > > Of course it's also worth testing the init script itself, or other > behaviours of the package when it's in its installed state rather > than just running out of the build tree. For that purpose, have you > considered autopkgtest (https://ci.debian.net/doc/)? A test with the > "needs-root" restriction can start and stop services. Hey Colin. Thanks for the feedback. I think autopkgtest(1) is a good route to go if I wanted to test it after the package had been generated and installed. But this is really the kind of test I'd like to perform before all of that while still within the build tree. -- 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#917384: ITP: python-mbed-host-tests -- tools to flash, reset and supervise testing on mbed-enabled devices
Package: wnpp Owner: Nick Morrott Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: python-mbed-host-tests Version : 1.4.4 Upstream Author : Przemyslaw Wirkus * URL : https://github.com/ARMmbed/htrun * License : Apache-2.0 Programming Lang: FIXME Description : tools to flash, reset and supervise testing on mbed-enabled devices mbed-host-tests is a module and utilities used during ARM Mbed Enabled device development for: * Driving test binary flashing * Device reset * Test execution I plan to maintain this package in the Debian Python Modules Team.
Bug#917385: ITP: golang-github-grokify-html-strip-tags-go -- export stripTags from html/template as strip.StripTags
Package: wnpp Severity: wishlist Owner: Nobuhiro Iwamatsu * Package name: golang-github-grokify-html-strip-tags-go Version : 0.0~git20180907.e9e4496-1 Upstream Author : John Wang * URL : https://github.com/grokify/html-strip-tags-go * License : BSD-3-clause Programming Lang: Go Description : Golang library to HTML StripTags This is a Go package containing an extracted version of the unexported stripTags function in html/template/html.go.
