Bug#883133: marked as done (general: Add new package header Upstream-Version:)
Your message dated Sat, 05 Sep 2020 18:35:43 +0200 with message-id <1599323743.11983.17.ca...@jasp.net> and subject line Re: Bug#883133: general: Add new package header Upstream-Version: has caused the Debian Bug report #883133, regarding general: Add new package header Upstream-Version: to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 883133: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883133 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: general Severity: wishlist Dear Maintainers, I propose to add new package header Upstream-Version: to contain the version as of the upstream of the package. The header should be optional because not every package has a definite upstream version. I am writing software which should call a program in specific version range (or fail to call it if the program in this version range is not installed). It should work for Debian and other systems (so I can use only the upstream version, not Debian version as is, to be compatible with other systems). Adding this header would ease the task to extract the upstream version of a specific package. It is possible now, but the algorithm of extracting the version of upstream may be different for every package. This is no good. My software should work not only on Debian. So writing a special algorithm to extract Debian version numbers (instead of simply looking into Upstream-Version:) is not a good way to do this task. Somebody, please report a similar idea for Fedora, SUSE and others. (I don't have it installed and don't know the proper way to report to them.) -- System Information: Debian Release: buster/sid APT prefers stable-updates APT policy: (990, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.13.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) --- End Message --- --- Begin Message --- El dj 27 de 08 de 2020 a les 10:25 +0200, Javier Serrano Polo va escriure: > May I close this report? No objection; closing. Reopen if needed. smime.p7s Description: S/MIME cryptographic signature --- End Message ---
Bug#883134: marked as done (general: Add new package header Upstream-Version:)
Your message dated Sat, 05 Sep 2020 18:35:43 +0200 with message-id <1599323743.11983.17.ca...@jasp.net> and subject line Re: Bug#883133: general: Add new package header Upstream-Version: has caused the Debian Bug report #883133, regarding general: Add new package header Upstream-Version: to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 883133: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883133 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: general Severity: wishlist Dear Maintainers, I propose to add new package header Upstream-Version: to contain the version as of the upstream of the package. The header should be optional because not every package has a definite upstream version. I am writing software which should call a program in specific version range (or fail to call it if the program in this version range is not installed). It should work for Debian and other systems (so I can use only the upstream version, not Debian version as is, to be compatible with other systems). Adding this header would ease the task to extract the upstream version of a specific package. It is possible now, but the algorithm of extracting the version of upstream may be different for every package. This is no good. My software should work not only on Debian. So writing a special algorithm to extract Debian version numbers (instead of simply looking into Upstream-Version:) is not a good way to do this task. Somebody, please report a similar idea for Fedora, SUSE and others. (I don't have it installed and don't know the proper way to report to them.) -- System Information: Debian Release: buster/sid APT prefers stable-updates APT policy: (990, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.13.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) --- End Message --- --- Begin Message --- El dj 27 de 08 de 2020 a les 10:25 +0200, Javier Serrano Polo va escriure: > May I close this report? No objection; closing. Reopen if needed. smime.p7s Description: S/MIME cryptographic signature --- End Message ---
Re: RFC: Final update of DEP-14 on naming of git packaging branches
On 8/31/20 8:53 AM, Raphael Hertzog wrote: > I already agreed that we can tweak the wording to document that it's I don't think the people on the list saw that message, as it had an attachment. It's below (unabridged). > OK to use debian/unstable as default branch even if you are not a > complex package that require multiple branches, provided that you will > not use debian/unstable when you decide to push something to > experimental. I do not see why we have to prohibit occasional uploads to experimental from debian/unstable. If this is permitted, then that also avoids the busywork of creating debian/experimental in that scenario. On 8/30/20 4:27 PM, Raphael Hertzog wrote: > Hello, > > On Sun, 30 Aug 2020, Richard Laager wrote: >> You could use debian/experimental all the time and then merge down to >> debian/unstable only when you're ready to upload and have chosen >> unstable. But I suspect your objection would be: that's unnecessary >> busywork. And I see that point. I would probably make the same >> objection, which means I think I agree with the debian/latest concept in >> your situation. > > You perfectly understood my reasoning. Thank you for making that effort. > >> I'm not sure if most package maintainers are doing this or not. I've >> always assumed that most people are targetting only unstable most of the >> time and that use of experimental is relatively rare. I could easily be >> wrong on that. > > I don't think that you are wrong. Most packages definitely only target > unstable and never use experimental. Then why give up the simplicity of only one choice and the clarity (and tooling advantages) of debian/unstable as the typical case, in favor of debian/latest? > But most packages also never need to maintain two development branches > in parallel. Only very big packages, linux or django for example, will > maintain different upstream versions in two parralel branches. > > Another thing that's quite certain is that you never know what the future > will bring you. And while you never had to use experimental, you might > have to at some point. > > In that sense, I find debian/latest more future-proof but I also > agree that for the few cases where we would have to use experimental, > it's not a big deal to have to create debian/experimental. > > Another thing to take into account is that DEP-14 has been drafted > as a vendor-neutral recommendation. I use it in the context of Kali > and there's no "unstable" release in Kali. We have "kali-dev". Ubuntu > only has codenames even for their development release. What's wrong with kali/kali-dev? I'd love to hear someone from Ubuntu weigh in on why ubuntu/latest would be better there. From my point of view (as someone who occasionally SRUs something in Ubuntu), having ubuntu/ is the right choice. When a new development release opens up, you would branch e.g. ubuntu/focal into ubuntu/groovy. Then ubuntu/focal continues to exist for SRUs (stable release updates). To me, my proposed branching model feels like it matches the Ubuntu development model 1:1. > Thus /latest is a better default for tools like git-buildpackage > and it makes sense for DEP-14 to endorse such a default branch as the > recommended name. > >> That is, I'm generally always targetting unstable and _not_ regularly >> using multiple releases, so the DEP-14 language "prohibits" me from >> using debian/unstable. This is what feels backwards to me. If I'm always >> targetting unstable, debian/latest (and previously debian/master) is >> less clear than debian/unstable. >> >> At a minimum, can we rework this in some way so the language does not >> require me to be regularly using multiple releases to use >> debian/unstable as a branch name? > > That seems entirely reasonable, yes. Can you try to make a proposal ? > > I attach the current markdown file with my not-yet pushed change that I > submitted for review here. > > Cheers, DEP-14 starts this section with a broad, "In general, packaging branches should be named according to the codename of the target distribution." On that, I think we all agree. Then it continues, "We differentiate however the case of development releases from other releases." Fundamentally, the scope of that exception is what we are discussing. Diffs available here (since this list refuses attachments and I can't figure out how to disable line wrapping in Thunderbird): https://paste.debian.net/1162793/ Proposal "A": My original position was that we limit that exception to using "unstable" and "experimental" instead of "sid" and what (I later learned) may or may not be "rc-buggy". This has the advantages that there is only one recommended default (instead of two or three) and the branch name (sans vendor) _always_ matches the changelog. Proposal "B": Raphael Hertzog, Russ Allbery, et al. upload to unstable or experimental depending on various factors, which notably may not be known a priori. In this case, it would be annoying busywork to have to
Re: RFC: Final update of DEP-14 on naming of git packaging branches
Hello Raphael, On Sun 30 Aug 2020 at 10:02AM -07, Sean Whitton wrote: > I think we should recommend debian/sid because for some years dgit has > been generating branches called dgit/sid. I think it would smooth the > integration between branches on salsa and branches on dgit.debian.org > if both always used codenames. Haven't heard back from you on this -- do you happen to know whether debian/sid or debian/unstable is in greater use on salsa right now? I would agree on standardising on d/unstable if it is already in significantly wider use. -- Sean Whitton signature.asc Description: PGP signature
Re: Mass bugs filing: autopkgtest should be marked superficial
Hi Paul, On Sat, Sep 5, 2020 at 1:56 AM Paul Wise wrote: > > On Fri, Sep 4, 2020 at 6:53 PM Sudip Mukherjee wrote: > > > If the test done in the autopkgtest does not provide significant test > > coverage then it should be marked with "Restrictions: superficial". > ... > > I am still trying to figure out a generalized method to find them but > > an initial script has found 83 packages. Attached is the dd-list. > > This sort of thing seems like something that will be an ongoing > problem so a more efficient way to solve it would be a lintian > warning, which should hopefully help prevent new occurrences. OTOH it > would be pretty hard to automatically check for these without a robust > shell parser. Perhaps morbig from Project CoLiS could be used for the > shell parsing and then a script could process the morbig output. > ShellCheck might be another option but it doesn't yet output parse > trees. We were hoping that this check can be added in lintian, but looking at #932862 it seems you have already requested that. :) I will have a look at morbig and see if I can use that in my script. Thanks for the idea. -- Regards Sudip
Bug#969620: ITP: metakernel -- Jupyter kernel base class
Package: wnpp Severity: wishlist Owner: Joseph Nahmias * Package name: metakernel Version : 0.27.0 Upstream Author : Metakernel Development Team * URL : https://github.com/Calysto/metakernel * License : BSD Programming Lang: Python Description : Jupyter kernel base class Metakernel is a Jupyter kernel base class in Python which includes core magic functions (including help, command and file path completion, parallel and distributed processing, downloads, and much more). It is used by numerous other kernels for Jupyter, including for my purposes the octave kernel. Happy to have co-maintainers and/or place it under the rubric of the Debian Python team. --Joe
