Re: [backintime] Switch the maintainer to "Debian Python Team (DPT)"
Carsten Schoenert writes: > There is a private list there such information *can* be given, again, > there is no rule that I need to do this. > There are options if some other DD believes a package is needing an > update, that process is called NMU (non maintainer upload). Or if you > think the other maintainer isn't doing his work in a time able manner, a > DD can salvage a package. > But these options are only doable by DDs! And that for a reason. > Yes, a new contributor requires a DD for sponsored uploads; however, new contributors are not discriminated against when salvaging a package. "Thanks to this [salvaging] process, new contributors should no longer be afraid to take over packages that have been neglected or entirely forgotten." https://www.debian.org/doc/manuals/developers-reference/pkgs.html#package-salvaging While it's true that no one can force anyone to do anything in Debian, it's also true that if someone salvages a chronically ignored package, that is a consequence of not having taken care of it, and then not having replied to the ITS bug for a month. All this assumes both good faith, and that new contributors educate themselves sufficiently well to submit upload candidates on debian-mentors (and file RFS) that sufficiently improves on the status quo of a neglected or forgotten package. It's important to note that the value expressed by this policy is that consistent, periodic (or better) long-term contributions are valued in Debian. It's also important to highlight that this value is attainable as a Debian Maintainer (uploading a set of approved packages), or as a Debian Contributor who requires a sponsor for all uploads. Best, Nicholas signature.asc Description: PGP signature
Re: [backintime] Switch the maintainer to "Debian Python Team (DPT)"
On Fri, Jul 28, 2023 at 11:08:38AM +, c.bu...@posteo.jp wrote: > So it is possible to have packages in the debian repo that don't run any > tests? I wasn't expecting this. Many packages don't have tests at all. For many of them tests are not possible or don't make much sense.
Re: [backintime] Switch the maintainer to "Debian Python Team (DPT)"
Dear Simon, thanks for your thougths. Am 28.07.2023 14:44 schrieb Simon McVittie: The other angle this could be approached from is as an upstream developer: IMHO this is the only angle it should be approached from because it is upstreams responsibility and Debian shouldn't waste resources and solving other ones problems. ;) fake HOME directory To my defense I have to say I'm not the founder just a member of the current upstream maintenance team. I haven't written that tests. Using a fake file ystem or temp folder as HOME won't solve problems with the test suite because there is much more hidden in it. In summary despite some exceptions there are no unit tests just integration and system tests.
Re: [backintime] Switch the maintainer to "Debian Python Team (DPT)"
On Fri, 28 Jul 2023 at 11:53:29 +0200, Carsten Schoenert wrote: > To quote from the BTS: > ---%<--- > > In 1.2 upstream added a test suite. We should run it during build > > (cd common && $(MAKE) test) but it needs to be able to write to the home > > directory, which is disabled on Debian auto-builders. Need to find > > a solution to that. > --->%--- > > To me it's clear what the problem is. The test requires a $HOME folder, but > the build environment doesn't provide something like this. If backintime uses $HOME, and doesn't rely on $HOME being the same as $(getent passwd $(id -u)|cut -d: -f6), then it might actually be possible to run its test suite with a dependency on a suitably new debhelper. In debhelper compatibility level 13, dh_auto_test sets $HOME to a temporary directory (#942111) which might well be enough to run the test suite non-destructively. If that's sufficient, I'm sure the maintainer of the backintime package would appreciate a tested patch sent to #940319. The way to test this would be to build backintime in sbuild, with a uid whose "official" home directory in /etc/passwd doesn't exist in the chroot. The other angle this could be approached from is as an upstream developer: as an upstream, would you really want running the backintime test suite to make potentially destructive changes to your real home directory? As an upstream developer of other packages, I wouldn't want that: if I have made an implementation mistake, I want to be able to find out about that by running the test suite, knowing that the test suite won't damage my real home directory. Making the test suite write to a mock home directory instead of to the real home directory, and changing or unsetting environment variables that point to the real home directory (again, see #942111) during automated testing, would make the test suite safer and more predictable. smcv
Re: [backintime] Switch the maintainer to "Debian Python Team (DPT)"
On Fri, 28 Jul 2023 at 11:08:38 +, c.bu...@posteo.jp wrote: > Am 28.07.2023 11:53 schrieb Carsten Schoenert: > > I don't see any workaround and there is non needed. The bug issue is > > about the not usable upstream test suite that would need to be called > > through d/rules. > > Maybe this is again about my expectations and wrong assumptions. > > So it is possible to have packages in the debian repo that don't run any > tests? I wasn't expecting this. > So Back In Time is in Debian for many years and never run tests on the > Debian build system? I'm shocked. Some packages can sensibly run tests at build-time, and for those packages, we usually try to do so. Some packages can't sensibly run tests at build-time (for instance if they need access to a GPU) so we don't; and for some packages we run tests at build-time, but we need to skip or ignore specific tests, or even ignore failure entirely, because the tests are known to be unreliable on some or all architectures. The only requirements on testing are: * the package's uploader has done whatever amount of automated or manual testing they feel is appropriate; * if automated tests *are* run, then they must succeed (or the failures must be explicitly ignored, if they're not believed to reflect a serious problem) * if the package runs build-time tests, they must meet the requirements in Policy (not writing to the user's home directory, not accessing the internet, etc.) If the uploader of backintime has tested it manually, either by running the test suite themselves or in real-world use of the updated package, then that's fine for an upload. smcv
Re: [backintime] Switch the maintainer to "Debian Python Team (DPT)"
Dear Carsten, thanks for taking time and replying. Am 28.07.2023 11:53 schrieb Carsten Schoenert: you really should read the Social Contract/DFSG, the Debian policy and the Developers reference a few times. I'll do. There is no rule that any DD or DM *must* do something in Debian, so you probably have the wrong expectations. Fascinating. I don't see any workaround and there is non needed. The bug issue is about the not usable upstream test suite that would need to be called through d/rules. Maybe this is again about my expectations and wrong assumptions. So it is possible to have packages in the debian repo that don't run any tests? I wasn't expecting this. So Back In Time is in Debian for many years and never run tests on the Debian build system? I'm shocked. I didn't realize this. I thought that the test suite is broken and not it never works. ;) Having a package in the official Debian repo was always kind of a quality certificate for me. ;) Sorry, but this is not your package! You are upstream, that's fine, but you want something to happen outside "your" world there you have no control of. We are here in Debian. Understood. I don't see the Debian Maintainer is wanting something from you as Upstream, so again, your expectation is wrong to me. There is a open report that the upstream test can't be running while build, if you can provide useful tips to solve this fine What else can be done than making upstream fix the buggy tests. ;) Ubuntu :D No way!
Re: [backintime] Switch the maintainer to "Debian Python Team (DPT)"
Hello Christian, Am 27.07.23 um 21:56 schrieb c.bu...@posteo.jp: Dear Carsten, thanks for your feedback, your kind words and your patience with my frustration. :) I was thinking about what it is what bothers me here. It is not that "the work" isn't done or bugs not fixed. It is that there is no reaction; zero; total silence. you really should read the Social Contract/DFSG, the Debian policy and the Developers reference a few times. https://www.debian.org/social_contract https://www.debian.org/doc/debian-policy/ https://www.debian.org/doc/manuals/developers-reference/ There is no rule that any DD or DM *must* do something in Debian, so you probably have the wrong expectations. The current Debian release is fresh. All of you maintainers have done a lot of extra work in the last weeks to get it done. The next release is two years in the future. Totally understandable if someone now would take half or one year off from the maintainers job. But this needs to be communicated somehow. A simple mail with "I'm on holiday for the next 6 months" would be OK for me. There is a private list there such information *can* be given, again, there is no rule that I need to do this. There are options if some other DD believes a package is needing an update, that process is called NMU (non maintainer upload). Or if you think the other maintainer isn't doing his work in a time able manner, a DD can salvage a package. But these options are only doable by DDs! And that for a reason. But without any reaction it feels to me that the package is not important to the maintainer. This depends heavily from the POV. As written, taking a 6 month off time might be an important time span for you, but this isn't true for other people. This is not about a simple bug ticket. I asked seriously in public on the list if the DPT could take over the package. Especially in this situation I would expect a reaction. Asking in public is quit impolite by me. But before I've done this I tried to reach jmw several times. Debian isn't working that way! It's all a project of volunteers, that why I'm did chose to be part of it. We are not bound to a company and we wont this to happen. So we all have no obligation to do something in a specific time window. If you expect this than you should move to Canonical/Ubuntu, thats there businesses is made off. ... Why can't only the maintainer answer this? You might haven't read all ticket comments or I wasn't able to make my question clear. The intention of my last comments to that ticket are to understand how Jonathan worked around the problem while packaging. It is my learning on the way becoming a Debian packager myself. The "workaround", if there is one, is visible within the Debian package source. https://salsa.debian.org/jmw/pkg-backintime/-/commits/debian I don't see any workaround and there is non needed. The bug issue is about the not usable upstream test suite that would need to be called through d/rules. As he describes the problem and I as understand, it must be impossible to build and package backintime for Debian. But as it is obvious it is somehow possible and I want to know how. I want to learn something specific about that packaging here. To quote from the BTS: ---%<--- In 1.2 upstream added a test suite. We should run it during build (cd common && $(MAKE) test) but it needs to be able to write to the home directory, which is disabled on Debian auto-builders. Need to find a solution to that. --->%--- To me it's clear what the problem is. The test requires a $HOME folder, but the build environment doesn't provide something like this. You nee to dive into the Debian package build process if you want to learn the "why". But this list is the wrong place for this. This list can help if you have specific questions about Python and Python packaging (as Mechtilde did mention). I don't understand what or who is blocking whom here? Is it that you feel you are blocked with your upstream work by the maintainer? [..] If you only think that the maintainer of backintime should be switched to the DPT then this is only a wish. And I don't think doing such a switch is improving the situation for you, still someone needs to do the work you requesting. All this is not about work in the meaning of fixing, uploading or something else. It is just about having a dialog. Without dialog I'm not able to learn and to take over packaging someday to save your resources. Not sure if it is against the Debian rules that upstream do its own Debian packaging. So you want and need to talk about how the Debian packaging is done? So you may be lucky to have some Debian folks around you which can explain this in one or more hacking session. Or you went to Debian Mentors. https://wiki.debian.org/DebianMentorsFaq https://mentors.debian.net/ https://lists.debian.org/debian-mentors/ This is the place there a few Debian contributors are willing to answer questions
Re: [backintime] Switch the maintainer to "Debian Python Team (DPT)"
Hello Christian, if you want to improve my understanding of Debian's build environment and learn more about it you should start to build yourself a package locally in a Debian's build environment. I went this way myself some years ago. We here at the list we can help you to do it yourself. I tried to document my way I do it. This documentation is public. It is like a reference where you can look into it to find answer for your questions. Otherwise ask here at the list and subscribe at debian-ment...@lists.debian.org. The reference is work in progress you can find the last version at https://salsa.debian.org/ddp-team/dpb (Sources) https://ddp-team.pages.debian.net/dpb/en_US/BuildWithGBP.pdf this is an automatic translation to English. The primary work is in German. Yes we can discus the problem in a separate thread. Regards Am 28.07.23 um 09:13 schrieb c.bu...@posteo.jp: Dear Mechtilde, thanks for taking time to reply. Am 28.07.2023 07:31 schrieb Mechtilde: Did you try to build the last released version? What are your problems to build backintime? At upstream I have no problems to build and test it because I'm upstream. ;) But in my understanding the problem described in the bug ticket is about building the package in Debian's build environment (servers?) where I have no idea about. Some of the checking tools (lintian?) might have a problem because my unit tests do write to home filesystem which is not allowed or possible in Debian's build environment. That is how I understand the ticket. At https://tracker.debian.org/pkg/backintime I can't find the right log or info describing the problem in detail. I'm not familiar with the system. That is why I ask questions like this because it is an opportunity to improve my understanding of Debian's build environment and learn more about all the fancy build-info (DD, UD, lintian, xyz, ...) links available. May I open a separate thread about the problem described in the ticket? Kind Christian -- Mechtilde Stehmann ## PGP encryption welcome ## F0E3 7F3D C87A 4998 2899 39E7 F287 7BBA 141A AD7F OpenPGP_signature Description: OpenPGP digital signature
Re: [backintime] Switch the maintainer to "Debian Python Team (DPT)"
Dear Mechtilde, thanks for taking time to reply. Am 28.07.2023 07:31 schrieb Mechtilde: Did you try to build the last released version? What are your problems to build backintime? At upstream I have no problems to build and test it because I'm upstream. ;) But in my understanding the problem described in the bug ticket is about building the package in Debian's build environment (servers?) where I have no idea about. Some of the checking tools (lintian?) might have a problem because my unit tests do write to home filesystem which is not allowed or possible in Debian's build environment. That is how I understand the ticket. At https://tracker.debian.org/pkg/backintime I can't find the right log or info describing the problem in detail. I'm not familiar with the system. That is why I ask questions like this because it is an opportunity to improve my understanding of Debian's build environment and learn more about all the fancy build-info (DD, UD, lintian, xyz, ...) links available. May I open a separate thread about the problem described in the ticket? Kind Christian
Re: [backintime] Switch the maintainer to "Debian Python Team (DPT)"
Hello Christian, a short comment to your log mail, Am 27.07.23 um 21:56 schrieb c.bu...@posteo.jp: Dear Carsten, You might haven't read all ticket comments or I wasn't able to make my question clear. The intention of my last comments to that ticket are to understand how Jonathan worked around the problem while packaging. It is my learning on the way becoming a Debian packager myself. As he describes the problem and I as understand, it must be impossible to build and package backintime for Debian. But as it is obvious it is somehow possible and I want to know how. I want to learn something specific about that packaging here. Did you try to build the last released version? What are your problems to build backintime? All this is not about work in the meaning of fixing, uploading or something else. It is just about having a dialog. Without dialog I'm not able to learn and to take over packaging someday to save your resources. Not sure if it is against the Debian rules that upstream do its own Debian packaging. Participating to Debian sometimes feels like talking to a wall. I want to learn and improve my skills to someday jump into the Debian packaging wheel. From my experience with this list it seems easier to have dialog with the DPT. You can ask here for specific help. this then you are welcome to become a member of the DPT by doing work on packages which are in the maintenance of the DPT Exactly! That is why I want my package being switch from jmw to the DPT to make it "in the maintenance of the DPT". So you want to process further something? Provide patches, improve packages, enhance documentation, do some kind of the work. That's the typical answers to that question. I hope I made my point clear now that I want and still do this. E.g. I checked all debian bug tickets for backintime. But I'm not able doing this further when there is no dialog. it might be sounds strange to you, but 5 or sometimes also 8 weeks and longer isn't a long time within Debian. I know this and I'm not that new to Debian. :) Waiting weeks and months for a reaction (not work) is IMHO not OK. Kind Christian Kind regards -- Mechtilde Stehmann ## PGP encryption welcome ## F0E3 7F3D C87A 4998 2899 39E7 F287 7BBA 141A AD7F OpenPGP_signature Description: OpenPGP digital signature
Re: [backintime] Switch the maintainer to "Debian Python Team (DPT)"
Dear Carsten, thanks for your feedback, your kind words and your patience with my frustration. :) I was thinking about what it is what bothers me here. It is not that "the work" isn't done or bugs not fixed. It is that there is no reaction; zero; total silence. The current Debian release is fresh. All of you maintainers have done a lot of extra work in the last weeks to get it done. The next release is two years in the future. Totally understandable if someone now would take half or one year off from the maintainers job. But this needs to be communicated somehow. A simple mail with "I'm on holiday for the next 6 months" would be OK for me. But without any reaction it feels to me that the package is not important to the maintainer. This is not about a simple bug ticket. I asked seriously in public on the list if the DPT could take over the package. Especially in this situation I would expect a reaction. Asking in public is quit impolite by me. But before I've done this I tried to reach jmw several times. On 2023-07-23 09:45 Carsten Schoenert wrote: > their work for Debian within their free and spare time and they can > decide when to work on something. It is the same on my upstream site. No one gets and wants applause. We do this for our own. > > There is also this bug ticket where I had specific questions (in > > August last year) only the maintainer can answer but got no > > reaction. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940319 > > Why can't only the maintainer answer this? You might haven't read all ticket comments or I wasn't able to make my question clear. The intention of my last comments to that ticket are to understand how Jonathan worked around the problem while packaging. It is my learning on the way becoming a Debian packager myself. As he describes the problem and I as understand, it must be impossible to build and package backintime for Debian. But as it is obvious it is somehow possible and I want to know how. I want to learn something specific about that packaging here. > I don't understand what or who is blocking whom here? > Is it that you feel you are blocked with your upstream work by the > maintainer? > [..] > If you only think that the maintainer of backintime should be > switched to the DPT then this is only a wish. And I don't think doing > such a switch is improving the situation for you, still someone needs > to do the work you requesting. All this is not about work in the meaning of fixing, uploading or something else. It is just about having a dialog. Without dialog I'm not able to learn and to take over packaging someday to save your resources. Not sure if it is against the Debian rules that upstream do its own Debian packaging. Participating to Debian sometimes feels like talking to a wall. I want to learn and improve my skills to someday jump into the Debian packaging wheel. From my experience with this list it seems easier to have dialog with the DPT. > this then you are welcome to become a member of the DPT by doing work > on packages which are in the maintenance of the DPT Exactly! That is why I want my package being switch from jmw to the DPT to make it "in the maintenance of the DPT". > So you want to process further something? > Provide patches, improve packages, enhance documentation, do some > kind of the work. That's the typical answers to that question. I hope I made my point clear now that I want and still do this. E.g. I checked all debian bug tickets for backintime. But I'm not able doing this further when there is no dialog. > it might be sounds strange to you, but 5 or sometimes also 8 weeks > and longer isn't a long time within Debian. I know this and I'm not that new to Debian. :) Waiting weeks and months for a reaction (not work) is IMHO not OK. Kind Christian
Re: [backintime] Switch the maintainer to "Debian Python Team (DPT)"
Hello Christian, Am 23.07.23 um 09:09 schrieb c.bu...@posteo.jp: Hello, On 2023-06-12 10:40 Jonathan Carter wrote: Adding DPT to at least uploaders and having the package VCS in the python-team namespace would probably be a good idea, but that's up to Jonathan Wiltshire. I have to state that after 5 weeks of waiting there is no reaction from Jonathan Wiltshire by mail, any bug-ticket (in context of backintime) and even IRC. it might be sounds strange to you, but 5 or sometimes also 8 weeks and longer isn't a long time within Debian. I know that my answer isn't helping you, it's simply quite all of the DMs and DDs are doing their work for Debian within their free and spare time and they can decide when to work on something. And Jonathan isn't only active as package maintainer, it's up to him what are his priorities and on what he wanted to work on. There is also this bug ticket where I had specific questions (in August last year) only the maintainer can answer but got no reaction. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940319 Why can't only the maintainer answer this? Also the issue is marked correctly as wishlist, typically this indicates also that the underlying issue isn't time critical. If you want to get applied something quickly then make it easy to the maintainer to accept the suggested modifications. Means prepare one (or more) patches which are easy and save to pick. I can't see anything like this within the bug report. For sure testing and test suites are always a good thing to add, but basically they are not needed for the functionality of a package. How can we proceed further? IMHO it is blocking the process waiting on someone who do not answer. I don't understand what or who is blocking whom here? Is it that you feel you are blocked with your upstream work by the maintainer? Do you like to have more power within the Debian package of your upstream work? Is there a issue in the Debian package that is causing trouble on the users? If you only think that the maintainer of backintime should be switched to the DPT then this is only a wish. And I don't think doing such a switch is improving the situation for you, still someone needs to do the work you requesting. The Debian policy is quite clear that a maintainer of a package has more or less the full power of the package, that's how Debian is build and also working for years. So far I've not seen any DPT member in the past weeks who would be willing to do work on the package backintime. If you want to improve this then you are welcome to become a member of the DPT by doing work on packages which are in the maintenance of the DPT, but becoming a DM will take time and requires to learn and accept the rules of being a DM. So you want to process further something? Provide patches, improve packages, enhance documentation, do some kind of the work. That's the typical answers to that question. -- Regards Carsten
Re: [backintime] Switch the maintainer to "Debian Python Team (DPT)"
Hello, On 2023-06-12 10:40 Jonathan Carter wrote: > Adding DPT to at least uploaders and having the package VCS in the > python-team namespace would probably be a good idea, but that's up to > Jonathan Wiltshire. I have to state that after 5 weeks of waiting there is no reaction from Jonathan Wiltshire by mail, any bug-ticket (in context of backintime) and even IRC. There is also this bug ticket where I had specific questions (in August last year) only the maintainer can answer but got no reaction. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940319 How can we proceed further? IMHO it is blocking the process waiting on someone who do not answer. Kind Christian Buhtz
Re: [backintime] Switch the maintainer to "Debian Python Team (DPT)"
Hi On 2023/06/12 09:51, c.bu...@posteo.jp wrote: Currently Jonathan Wiltshire is official DM for that package. I'm sure he makes a good job as DM. But other packages might have higher priorities. He do not response in time and in some topics never. As upstream maintainer I miss the dialog with "my distro maintainer". Also there was a RFS [2] without concrete response/decision. It wasn't clear to me if it wasn't uploaded because of the Freeze or just because no one was there to do it. (just for the avoidance of confusion, I'm an entirely different Jonathan) You're very likely correct that the freeze impacted the upload. To upload newer versions of software (even for bug fixes) so late in the freeze, you have to write a proper justification to the release team and convince them that the benefit of the upload outweighs the risk, so in the last few weeks of the freeze, very few packages get updated. Adding DPT to at least uploaders and having the package VCS in the python-team namespace would probably be a good idea, but that's up to Jonathan Wiltshire. -Jonathan
