Re: Do we want to Require or Recommend DH
Hi Tollef, On Wed, May 15, 2019 at 09:54:50PM +0200, Tollef Fog Heen wrote: > ]] Andreas Tille > > > Can you give an example for a package that has a non-dh rules file > > "working for years" that gives as a result a package with no lintian > > warnings without changing this d/rules file? > > If you're talking about the binary package, fortunes-bofh-excuses. It > has some lintian warnings on the source package (primarily because it's > not been uploaded for more than ten years) of which only two out of six > warnings would be handled automatically by dh. >From a developer point of view I'm talking about *any* lintian warnings so for sure also about source package warnings. > (Yes, also not an important package in the grand scheme of things, and > I'm not disagreeing that using dh is a good thing overall. I should > probably upload it just to get some of the dust off it.) :-) Kind regards Andreas. -- http://fam-tille.de
Re: Towards lapack / lapack64 packaging
Hi Sébastien, On 2019-05-15 16:23, Sébastien Villemot wrote: >> Sébastien provided some possible solutions: >> >> 1. build a 64-bit indexing variant of src:lapack >> 2. provide a liblapack64-pic (Sébastien prefer this) > > First, note that solution 1 is a superset of solution 2 (i.e. we would > also provide liblapack64-pic in solution 1). > > Actually solution 1 is my preferred one. > > But since I do not have the time to work on it in the immediate future, > and since you’ve said you were not interested in investing time in non- > optimized implementations, I would be ok if you were implementing > solution 2 as an intermediate step. Then I could implement 1 later. Let's implement solution 1. That enables us to provide a unified dependency template for libblas64.so and liblapack64.so* . The current dependency template for src:blis' libblas64.so.3 is: libblas64.so.3 libblis64-2 | libblas64.so.3 #MINVER# which is not aligned with 32-bit indexing version, due to the absence of a standard one. Let's first comment out the lapack64 bits for openblas and get blas64 updates uploaded. Then I'll look into updating the netlib for blas64 and lapack64. This is technically the best choice, yet requires some more time to be done. >> 3. disentangle src:lapack and src:openblas and just >> use src:openblas's embedded copy of src:lapack. >> (currently that embedded copy is removed from debian >> source) > > I don’t think this is an acceptable solution. I deliberately stripped > the embedded copy of src:lapack in order to follow best practices. See > Debian Policy §4.13 and https://wiki.debian.org/EmbeddedCodeCopies Well, I understand that but human sometimes thinks about slacking off and doing something ungraceful. >> (2) confirming details for our standard of BLAS/LAPACK virtual packages >> --- > >> 1. BLAS/CBLAS packages looks relatively tidy, except Atlas >>which splitted CBLAS into a separate libcblas.so . > > This is not true, as you can easily verify by running: > > nm -D /usr/lib/x86_64-linux-gnu/atlas/libblas.so.3 | grep cblas_ Oops, I overlooked that. >>That's a pitfall and numpy had ever fell into it: #913567 > > The numpy issue is unrelated. My point is that the existence of atlas' libcblas.so is sometimes misguiding: when a package asks for a cblas library, the maintainer will first apt search libcblas and they will find nothing. Then they will apt-file search libcblas and find atlas and set it as the dependency. Maintainers without enough background on BLAS / LAPACK are likely to be misguided. And they don't necessarily know that Debian's default Atlas package (without tuning) is really slow. >>Debian's Atlas is terribly slow due to ISA baseline.[2] > > Note that ATLAS is meant to be recompiled locally in order to get best > performance, as explained in the extended description of the package. > But it’s true that it’s slower than OpenBLAS and BLIS. An untuned Atlas library (apt install libatlas3-base), running in multi-threaded mode is even slower than BLIS that runs in single-threaded mode. To users who don't have enough background or who don't read the doc, this is a performance pitfall. >>Should we squash Atlas's libcblas.so back into it's >>libblas.so ? [3] Like all other alternative libraries did. > > As said above, this is already done. Indeed. There is nothing to fix. >> 2. LAPACK and LAPACKE are well-seperated into different >>shared libraries. Sometimes LAPACKE is simply not >>built. LAPACK has been registered in the alternatives >>system: "liblapack.so", "liblapack.so.3". >> >>Can we confirm that it's fine to provide only LAPACK >>via liblapack.so and don't register LAPACKE in the >>alternatives system? > > Yes I think it’s fine. LAPACKE is only a thin C wrapper above LAPACK, > and there is only one implementation of that wrapper. And liblapacke.so > is dynamically linked against liblapack.so, so it will pick whatever > LAPACK implementation is currently selected in the alternatives system. ACK. Thanks for confirming, that saved me much time for reading the code. > Thanks for your work on BLAS/LAPACK,
Re: Do we want to Require or Recommend DH
Hello,
On Tue 14 May 2019 at 12:30PM +01, Ian Jackson wrote:
> Sean Whitton writes ("Re: Do we want to Require or Recommend DH"):
>> I agree with Scott's emphasis on the distinction between new and
>> existing packages. Perhaps application of the distinction could be
>> extended: perhaps there are other things that we could require of new
>> packages, while creating no expectation that these requirements be met
>> of older packages.
>>
>> In general, if a policy requirement or convention should apply to new
>> packages, then it should apply to existing packages, too. But
>> specifically where applying the requirement to an existing package is
>> hugely more work than applying it to a new package, perhaps the
>> requirement ought to be limited to new packages alone.
>
> There is a big distinction between recommendations which directly
> affect the functioning of the binary packages, and recommendations
> which make future development easier.
Good point.
> For the latter - and use of dh is an example - it makes a lot of sense
> to make the recomendations stronger for new packages.
>
> I also think it would be very valuable for policy to recommend things
> like this as the usual case, without mandating them. If for any
> reason the maintainer doesn't want to use dh, then they can leave a
> wontfix bug open (or something) to document the reasons.
It might be useful to note here that patches to debian-policy which
suggest using particular tools, without using "recommends", "should" or
"must" (etc.), do not need to go through the Policy Changes Process, and
can just be applied immediately.
For example, in Policy we currently have:
The easiest way to call "dpkg-shlibdeps" correctly is to use a
package helper framework such as debhelper. If you are using
debhelper, the "dh_shlibdeps" program will do this work for you.
and
Note that under some circumstances it may be useful to install a
shared library unstripped, for example when building a separate
package to support debugging. The debhelper *dh_strip`* tool can
create such packages automatically.
This sort of text, which is informative rather than normative, does not
need to go through the consensus-building process.
--
Sean Whitton
signature.asc
Description: PGP signature
Re: dgit FAQ
Hello, On Tue 14 May 2019 at 01:59PM +10, Ben Finney wrote: > One issue I noticed: > > git-buildpackage and git-dpm users are fully supported […] > > That seems to contradict earlier statements that “separate > Debian-packaging-only repository” workflow (which is supported by > Git-BuildPackage) is currently not supported by DGit. > > Is the DGit FAQ wrong on that point? Thanks, fixed. -- Sean Whitton signature.asc Description: PGP signature
Bug#929047: ITP: libubootenv -- Library to access U-Boot environment
Package: wnpp Severity: wishlist Owner: Nobuhiro Iwamatsu * Package name: libubootenv Version : 0.1 Upstream Author : Stefano Babic * URL : https://github.com/sbabic/libubootenv * License : LGPL-2.1 Programming Lang: C Description : Library to access U-Boot environment libubootenv is a library that provides a hardware independent way to access to U-Boot environment. U-Boot has its default environment compiled board-dependently and this means that tools to access the environment are also board specific, too.
Re: Do we want to Require or Recommend DH
]] Andreas Tille > Can you give an example for a package that has a non-dh rules file > "working for years" that gives as a result a package with no lintian > warnings without changing this d/rules file? If you're talking about the binary package, fortunes-bofh-excuses. It has some lintian warnings on the source package (primarily because it's not been uploaded for more than ten years) of which only two out of six warnings would be handled automatically by dh. (Yes, also not an important package in the grand scheme of things, and I'm not disagreeing that using dh is a good thing overall. I should probably upload it just to get some of the dust off it.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Bug#929040: ITP: tty-solitaire -- klondike solitaire game for text terminal
Package: wnpp Severity: wishlist Owner: Marcin Owsiany * Package name: tty-solitaire Version : 1.1.1 Upstream Author : Murilo Pereira * URL : https://github.com/mpereira/tty-solitaire * License : MIT Programming Lang: C Description : klondike solitaire game for text terminal This game runs in any terminal with UTF-8 support.
Re: Towards lapack / lapack64 packaging
Hi Lumin, Le mercredi 15 mai 2019 à 08:39 -0700, Mo Zhou a écrit : > (1) building problem about OpenBLAS's liblapack64.so > - > > Sébastien provided some possible solutions: > > 1. build a 64-bit indexing variant of src:lapack > 2. provide a liblapack64-pic (Sébastien prefer this) First, note that solution 1 is a superset of solution 2 (i.e. we would also provide liblapack64-pic in solution 1). Actually solution 1 is my preferred one. But since I do not have the time to work on it in the immediate future, and since you’ve said you were not interested in investing time in non- optimized implementations, I would be ok if you were implementing solution 2 as an intermediate step. Then I could implement 1 later. > Yes, the solution *2 poses very little workload because > we just need to rebuild lapack with fortran flag "-i8". > > However, I'm thinking about the 3-rd solution: > > 3. disentangle src:lapack and src:openblas and just > use src:openblas's embedded copy of src:lapack. > (currently that embedded copy is removed from debian > source) I don’t think this is an acceptable solution. I deliberately stripped the embedded copy of src:lapack in order to follow best practices. See Debian Policy §4.13 and https://wiki.debian.org/EmbeddedCodeCopies > (2) confirming details for our standard of BLAS/LAPACK virtual packages > --- > 1. BLAS/CBLAS packages looks relatively tidy, except Atlas >which splitted CBLAS into a separate libcblas.so . This is not true, as you can easily verify by running: nm -D /usr/lib/x86_64-linux-gnu/atlas/libblas.so.3 | grep cblas_ >That's a pitfall and numpy had ever fell into it: #913567 The numpy issue is unrelated. >Debian's Atlas is terribly slow due to ISA baseline.[2] Note that ATLAS is meant to be recompiled locally in order to get best performance, as explained in the extended description of the package. But it’s true that it’s slower than OpenBLAS and BLIS. >Should we squash Atlas's libcblas.so back into it's >libblas.so ? [3] Like all other alternative libraries did. As said above, this is already done. > 2. LAPACK and LAPACKE are well-seperated into different >shared libraries. Sometimes LAPACKE is simply not >built. LAPACK has been registered in the alternatives >system: "liblapack.so", "liblapack.so.3". > >Can we confirm that it's fine to provide only LAPACK >via liblapack.so and don't register LAPACKE in the >alternatives system? Yes I think it’s fine. LAPACKE is only a thin C wrapper above LAPACK, and there is only one implementation of that wrapper. And liblapacke.so is dynamically linked against liblapack.so, so it will pick whatever LAPACK implementation is currently selected in the alternatives system. Thanks for your work on BLAS/LAPACK, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Re: QA expectations (Was: Do we want to Require or Recommend DH)
On Wed, May 15, 2019 at 09:28:59AM +0100, Simon McVittie wrote: > Prior art: Ubuntu already does this, gating the transition with a version > of Debian's testing migration scripts that has been configured for a 0 day > delay for all urgencies. Yes. Colin Watson even had a talk about this in Vaumarcus. http://penta.debconf.org/dc13_schedule/events/1028.en.html Copying the strategy to Debian failed to gain traction thus far. I wonder whether we could do this opt-in (or maybe as some external service that forwards tested packages to the archive) anyhow. I have little clue about what would be required to implement it in the archive. > Ubuntu is more able to do this than Debian, because Ubuntu's slowest, > least reliable and least-well-supported architectures are faster, more > reliable and better-supported than Debian's. I'm not sure that we really > want to be waiting for important fixes (especially in large packages > like compilers, web browsers and the kernel) to build successfully on > mips(el), or requiring that their build-time tests have few enough race > conditions to be successful even on slower architectures, before they > can reach the part of the archive that developers use in practice? Given my experience with Multi-Arch: same skews in unstable, it does not appear to me that packages get stuck for that long. If they do, that's due to a FTBFS (which is exactly the thing we want to prevent from entering unstable). buildd speed is a concern for other reasons, so if an architecture fails to keep up for a longer time, it should likely be demoted to ports. Helmut
Towards lapack / lapack64 packaging
Hi science team,
I'm trying to add multi-flavor support to the openblas
package, as a part of the ongoing BLAS64 + LAPACK64 work.
However, there is some problems need to be discussed.
Two problems will be discussed in this email:
(1) building problem about OpenBLAS's liblapack64.so
(2) confirming details for our standard of BLAS/LAPACK virtual packages
To any other developers: If you maintain a (recursive)
reverse-dependency of libblas.so or liblapack.so, please
at least read the point 1 in section (2)
for a pitfall warning about performance.
(1) building problem about OpenBLAS's liblapack64.so
-
For those who are not sure what the "64" suffix in BLAS64
and LAPACK64 means:
BLAS and LAPACK are very important numerical
linear algebra librarries that operates contiguous
numerical arrays.
libblas.so and liblapack.so provides functions
with 32-bit array indexing, e.g.
float cblas_asum(int N, float* X, int incX);
which calculates
sum_{i=1}^N abs(x_i)
However, "int" is 32-bit long on amd64.
This simply doesn't work with arrays containing
more than 2^31 elements. Hence we need a 64-bit
indexing variant, for example:
float cblas_asum(int64_t N, float* X, int64_t incX);
Note, as pointed out by Ben long time ago, the
correct type for pointer offset should be size_t
or ptrdiff_t, IIRC.
The 64-bit variants are needed by some scientific
computing users, and packages in cluding Julia language.
Sébastien pointed out that the `liblapack64.so` library
in my implementation[1] mixed 32-bit indexing code
and 64-bit indexing code. Because
liblapack64.so is compiled objects from:
(1) bin:liblapack-pic (32-bit indexing static lib)
(2) openblas's optimized lapack subset
when I turn on the INTERFACE64=1 flag in order to
build a 64-bit variant, the linker just mixes
symbols from 32-bit indexing bin:liblapack-pic
and symbols from 64-bit indexing openblas code,
yielding a quite problematic liblapack64.so
Sébastien provided some possible solutions:
1. build a 64-bit indexing variant of src:lapack
2. provide a liblapack64-pic (Sébastien prefer this)
Yes, the solution *2 poses very little workload because
we just need to rebuild lapack with fortran flag "-i8".
However, I'm thinking about the 3-rd solution:
3. disentangle src:lapack and src:openblas and just
use src:openblas's embedded copy of src:lapack.
(currently that embedded copy is removed from debian
source)
This (maybe) poses even less workload to me compared to *2 .
[1] https://salsa.debian.org/science-team/openblas/tree/lumin/
(2) confirming details for our standard of BLAS/LAPACK virtual packages
---
Disambiguity is very important before starting this section.
Everything will definitely turn into a mess if I don't do so.
In this section, I'll use the following notations:
* Uppercased "BLAS" means the standard BLAS API and ABI,
fortran-based. Debian's virtual packages libblas.so and
libblas.so.3 provide BLAS API and ABI. A typical BLAS
symbol looks like "sasum_" (suffixed by an underscore)
* Uppercased "CBLAS" means the c-version of the standard
BLAS API and ABI. A typical CBLAS symbol looks like
"cblas_sasum". (prefixed by "cblas_") The CBLAS ABI
has been squashed into libblas.so{,.3} . It's not
recommended to link against libcblas.so if you
found one in the Atlas package -- which splitted
the BLAS and CBLAS ABI into different shared objs.
* Uppercased "LAPACK" means the standard LAPACK API and ABI,
also fortran-based. Debian's liblapack.so and liblapack.so.3
provides the ABI.
* Uppercased "LAPACKE" means the c-version of the LAPACK
API and ABI. On Debian it is shipped by bin:liblapacke,
instead of squashed into liblapack.so (sounds a bit messy)
* Uppercased BLAS64, CBLAS64, LAPACK64, LAPACKE64 are
the corresponding 64-bit indexing variants.
It's important to differentiate fortran stuff from C stuff
because fortran stores array in column-major, while C in
row-major. Now let me point out some messy stuff:
1. BLAS/CBLAS packages looks relatively tidy, except Atlas
which splitted CBLAS into a separate libcblas.so .
That's a pitfall and numpy had ever fell into it: #913567
Debian's Atlas is terribly slow due to ISA baseline.[2]
Should we squash Atlas's libcblas.so back into it's
libblas.so ? [3] Like all other alternative libraries did.
2. LAPACK and LAPACKE are well-seperated into different
shared libraries. Sometimes LAPACKE is simply not
built. LAPACK has been registered in the alternatives
system: "liblapack.so", "liblapack.so.3".
Can we confirm that it's fine to provide only LAPACK
via liblapack.so and don't register LAPACKE in the
alternatives system?
If most reverse dependencies only require the fortran
Re: Do we want to Require or Recommend DH
On Mon, May 13, 2019 at 05:58:47PM +0200, Thomas Goirand wrote: Why would one want to switch that one to something else? The package, basically, consists of a shell script and a man page only. The minimalism of this package doesn't require an over-engineered dh sequencer, does it? I maintain one of the simplest possible packages (in non-free), doom-wad-shareware, that is even simpler: it consists of three files total: /usr/share/doc/doom-wad-shareware/changelog.Debian.gz /usr/share/doc/doom-wad-shareware/copyright /usr/share/games/doom/doom1.wad For the source package, I thought "why do I need debhelper for such a simple package". And so I did things by hand instead¹, and I still screwed something up². This is clearly a stupid case of premature optimisation, yak shaving, etc.; I suspect many other instances of "why bother for such a simple package" in the archive have elements of these too. (An unrelated, but amusing mess-up in this trivial package: for the first 11 years, there was a version mismatch between what was actually in the .deb and what the version claimed) 1. https://sources.debian.org/src/doom-wad-shareware/1.9.fixed-2/debian/rules/ 2. https://tracker.debian.org/news/449441/accepted-doom-wad-shareware-19fixed-2-source-all/ -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Bug#929024: ITP: routinator -- An RPKI Validator
Package: wnpp Severity: wishlist Owner: Marco d'Itri * Package name: routinator Version : 0.3.3 Upstream Author : NLnet Labs * URL : https://nlnetlabs.nl/rpki * License : BSD Programming Lang: Rust Description : An RPKI Validator The Routinator 3000 is an RPKI relying party software: network operators can configure their BGP-speaking routers to use it to cryptographically validate the routes received from third parties. -- ciao, Marco signature.asc Description: PGP signature
Re: Do we want to Require or Recommend DH
On Tue, May 14, 2019 at 02:27:30PM +0800, Paul Wise wrote: I think conversion to dh should only be done when doing hostile hijacking of packages, salvaging packages, adopting packages, orphaning packages or team/maintainer uploads and only if the person doing the conversion builds the package twice (with and without dh), inspects the resulting changes to the binary packages with diffoscope and is confident that each change is appropriate. Here you state your opinion but you haven't provided any rationale for it. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: NMUs: Do we want to Require or Recommend DH
Hi, On Wed, May 15, 2019 at 02:09:14PM +0200, Benjamin Drung wrote: > Am Mittwoch, den 15.05.2019, 11:31 +0200 schrieb Enrico Zini: > > I'd propose to recommend dh as the default build system, and document > > in README.source if there are reasons to use something else. > > > > At that point, one could look at README.source to see if changing > > build system would be an possible strategy for fixing bugs in an NMU. The README.source idea is good ... > Or introduce a lintian check for not using dh. Then the maintainer > could override lintian and document the reason for it in the override. ... but I think the documented lintian override is better since it is more connected to code than free text. Kind regards Andreas. -- http://fam-tille.de
Re: NMUs: Do we want to Require or Recommend DH
Enrico Zini writes ("Re: NMUs: Do we want to Require or Recommend DH"):
> I'd propose to recommend dh as the default build system, and document in
> README.source if there are reasons to use something else.
>
> At that point, one could look at README.source to see if changing build
> system would be an possible strategy for fixing bugs in an NMU.
This is a great idea. Obviously such a policy/process change would
have to come with a significant lead time so that everyone would have
a chance to do an upload with an appropriate README.source.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: binutils security support (Re: fixing debian-security-support upgrades from stretch (for good))
On Tue, May 14, 2019 at 11:39:50PM +0200, Moritz Mühlenhoff wrote: > Holger Levsen schrieb: > > (and yes, I also agree this is quite a desaster, just like > > kde4libs/khtml only is suitable for trusted content, which IOW means, > > one should not use konqueror or kmail on the interweb.) > That is the upstream status quo and not in any way specific to Debian, > we're just the only ones transparent about it instead of wiping it > under the carpet. yes, and I'm thankful for this. apologies if my mail didn't express that. -- tschau, 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: NMUs: Do we want to Require or Recommend DH
Am Mittwoch, den 15.05.2019, 11:31 +0200 schrieb Enrico Zini: > I'd propose to recommend dh as the default build system, and document > in README.source if there are reasons to use something else. > > At that point, one could look at README.source to see if changing > build system would be an possible strategy for fixing bugs in an NMU. Or introduce a lintian check for not using dh. Then the maintainer could override lintian and document the reason for it in the override. -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
dh_testroot usage is still always required (was Re: Do we want to Require or Recommend DH)
On Wed, 2019-05-15 at 09:18:26 +0100, Simon McVittie wrote: > It uses dh_testroot, so it probably can't have Rules-Requires-Root: no, > and needs to be built as (fake)root indefinitely - even though a package > this simple can almost certainly be built correctly without fakeroot. You've mention this twice in the thread, and this is incorrect. Actually, removing dh_testroot would be just harmful. Whether a package is to be built with R³ or not depends in most part on the builder environment, not the packaging. If you use a new enough dpkg-buildpackage, then it will enable it if the packaging allows it, otherwise it should require (fake)root; or if calling debian/rules by hand, even when the packaging has specified it can be built with no R³. (See dpkg itself for an example of this.) Thanks, Guillem
Re: NMUs: Do we want to Require or Recommend DH
Quoting Enrico Zini (2019-05-15 11:31:46) > On Tue, May 14, 2019 at 02:30:52PM -0400, Sam Hartman wrote: > > > How do we feel about people making build system conversions when > > those conversion make it easier to fix some other bug that they are > > fixing as part of an NMU? > > That is, imagine that a package is mishandling the combination of > > systemd units and an init script. As someone preparing an NMU, is > > it reasonable to move to dh compat 12 from some other build system > > if I believe doing so will make it easier for me to fix the bug and > > verify the fix? > > I see various scenarios: > > - if a package is generally actively maintained, except the >maintainer is currently unresponsive for some reason and there is a >RC bug to fix, I could understand frowning upon a build system >conversion in an NMU. > > - if a package has bugs that can all be fixed trivially with a build >system conversion, I would see no reason not to do such a >conversion, even in an NMU. > > - a change of build system in a complex package would be more >controversial than in a trivial package. > > - if a package has had an inactive and unresponsive maintainer for a >long time, it would indeed be a case for salvaging. > >I could however imagine someone having enough energy to dust off >old packages in the archive, while not having enough energy to pick >up maintenance of lots of old dusty packages. > >I would consider the idea of salvaging+orphaning, like following >the salvaging procedure but setting the maintainer to qa instead. > > - I'd say that orphaned packages can be uncontroversially be >converted to dh. Very well said. I agree ith all of it. > With a consensus of having dh as the default build system, and the > understanding that some packages have good reasons not to use dh, I'd > like a way to tell when a package is not using dh for a reason, from > when a package is not using dh because the maintainer has not gotten > around to it yet. > > I'd propose to recommend dh as the default build system, and document > in README.source if there are reasons to use something else. > > At that point, one could look at README.source to see if changing > build system would be an possible strategy for fixing bugs in an NMU. Great suggestion! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Nie masz pomysłu na nowy post? Poprowadzimy Twój FanPage.
Dzień dobry, pragniemy zwrócić Państwa uwagę na jedną z najskuteczniejszych metod pozyskiwania klientów oraz zarabiania pieniędzy. Jesteśmy profesjonalistami, którzy skutecznie administrują *_FanPage’ami na Facebook’u. _* Dzięki zgromadzonemu doświadczeniu możemy śmiało powiedzieć, że grono zadowolonych klientów odniosło dzięki nam sukces i pomnożyło zarobione pieniądze. Jeżeli zainteresowaliśmy Państwa tą tematyką, prosimy o przesłanie odpowiedzi postaci słowa " *_TAK "_*. Skontaktujemy się z Państwem i przedstawimy szczegóły. . . . . Z poważaniem Michał Klos
Re: NMUs: Do we want to Require or Recommend DH
On Tue, May 14, 2019 at 02:30:52PM -0400, Sam Hartman wrote: > How do we feel about people making build system conversions when those > conversion make it easier to fix some other bug that they are fixing as > part of an NMU? > That is, imagine that a package is mishandling the combination of > systemd units and an init script. As someone preparing an NMU, is it > reasonable to move to dh compat 12 from some other build system if I > believe doing so will make it easier for me to fix the bug and verify > the fix? I see various scenarios: - if a package is generally actively maintained, except the maintainer is currently unresponsive for some reason and there is a RC bug to fix, I could understand frowning upon a build system conversion in an NMU. - if a package has bugs that can all be fixed trivially with a build system conversion, I would see no reason not to do such a conversion, even in an NMU. - a change of build system in a complex package would be more controversial than in a trivial package. - if a package has had an inactive and unresponsive maintainer for a long time, it would indeed be a case for salvaging. I could however imagine someone having enough energy to dust off old packages in the archive, while not having enough energy to pick up maintenance of lots of old dusty packages. I would consider the idea of salvaging+orphaning, like following the salvaging procedure but setting the maintainer to qa instead. - I'd say that orphaned packages can be uncontroversially be converted to dh. With a consensus of having dh as the default build system, and the understanding that some packages have good reasons not to use dh, I'd like a way to tell when a package is not using dh for a reason, from when a package is not using dh because the maintainer has not gotten around to it yet. I'd propose to recommend dh as the default build system, and document in README.source if there are reasons to use something else. At that point, one could look at README.source to see if changing build system would be an possible strategy for fixing bugs in an NMU. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: QA expectations (Was: Do we want to Require or Recommend DH)
On Tue, 14 May 2019 at 18:19:47 +0200, Johannes Schauer wrote: > So maybe instead of creating unstable-proposed, stuff should move from > buildd-unstable to unstable only after it successfully passed all kinds of > automatable QA tests? Prior art: Ubuntu already does this, gating the transition with a version of Debian's testing migration scripts that has been configured for a 0 day delay for all urgencies. The down side of this is that families of packages occasionally get stuck in their incoming-equivalent because of versioned dependencies, and a transition is needed to get them into their testing-equivalent. Perhaps some Ubuntu developers could comment on the extent to which this is a practical problem? > It could also have other nice properties that currently only testing has, > like no Multi-Arch:same version skews because stuff could only move to > unstable > after it has been built on all arches. Ubuntu is more able to do this than Debian, because Ubuntu's slowest, least reliable and least-well-supported architectures are faster, more reliable and better-supported than Debian's. I'm not sure that we really want to be waiting for important fixes (especially in large packages like compilers, web browsers and the kernel) to build successfully on mips(el), or requiring that their build-time tests have few enough race conditions to be successful even on slower architectures, before they can reach the part of the archive that developers use in practice? smcv
Re: Do we want to Require or Recommend DH
On Mon, 13 May 2019 at 17:58:47 +0200, Thomas Goirand wrote: > Now, I have another example, which is quite the opposite one of what you > gave as example: > > https://salsa.debian.org/openstack-team/debian/openstack-debian-images/blob/debian/stein/debian/rules > > Why would one want to switch that one to something else? The package, > basically, consists of a shell script and a man page only. I would personally *especially* use dh for packages this simple. It uses dh_testroot, so it probably can't have Rules-Requires-Root: no, and needs to be built as (fake)root indefinitely - even though a package this simple can almost certainly be built correctly without fakeroot. At some point in the past someone, probably you, has had to think about: - which dh_foo helpers need to be included in the list and which can be excluded - which order they go in which has probably been done correctly, but maybe not - I can't tell. The fact that they might have been done incorrectly isn't so bad: if they're wrong it's just a bug, and we can fix bugs. The fact that it would take thought to work out whether they're correct is more problematic. At some point in the past someone, probably you, has had to make this package Policy-compliant when the -arch and -indep targets became mandatory in order to make Build-Depends-Indep practically useful (perhaps this package is new enough that you did that as part of its initial packaging, but either way, someone had to think about it). Adding the -arch and -indep targets went as slowly as it did because many packages needed (trivial) per-package changes to enact it. Part of the value of a dh rules file is that (as Ian Jackson said elsewhere in this thread) the boilerplate part is trivial, and each non-boilerplate part (override target) indicates something that is unusual about this package. A minimal dh rules file immediately tells a reader "this is a completely ordinary build process" and that's a valuable thing to convey to a reader. smcv
Re: NMUs: Do we want to Require or Recommend DH
Quoting Scott Kitterman (2019-05-15 04:47:48) > > > On May 15, 2019 1:13:52 AM UTC, Paul Wise wrote: > >On Wed, May 15, 2019 at 2:31 AM Sam Hartman wrote: > > > >> How do we feel about people making build system conversions when > >> those conversion make it easier to fix some other bug that they are > >> fixing as part of an NMU? > > > >If the maintainer is MIA enough to not express an opinion when asked > >if adding a dh conversion to the NMU is fine, probably the package > >should be orphaned/salvaged instead of NMUed, which would bring the > >dh conversion into scope. > > I'd think the timeline for that would be longer than the week or two > it takes to do an NMU. Yes the timeline of an NMU being short is the very issue as I see it: Switching build system may be easy to do but less easy to maintain for the maintainer - regardless of popularity in general. No, major package refactoring like change of build system is unacceptable in NMUs, because it strongly affects long-term maintenance. Real underlying question seems instead to be this: Do we tolerate maintainers using a "wrong" packaging style - i.e. an unpopular style fewer find easy to do NMUs for? Yes, let's recommend what is popular. But not this. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
