Bug#951418: ITP: golang-gopkg-errgo.v2 -- Dependable Go errors with tracebacks, version 2
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-gopkg-errgo.v2 Version : 2.1.0-1 Upstream Author : Roger Peppe * URL : https://github.com/go-errgo/errgo * License : BSD-3-clause Programming Lang: Go Description : Dependable Go errors with tracebacks, version 2 Package errgo provides some primitives for error creation and handling. . It provides primitives for wrapping and annotating errors without exposing implementation details unnecessarily. Reason for packaging: Needed by golang-github-rogpeppe-go-internal, which in turn is needed by hugo 0.60.0+
Bug#951419: ITP: golang-github-rogpeppe-go-internal -- Selected Go-internal packages factored out from the standard library
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-rogpeppe-go-internal Version : 1.3.0-1 Upstream Author : Roger Peppe * URL : https://github.com/rogpeppe/go-internal * License : BSD-3-clause Programming Lang: Go Description : Selected Go-internal packages factored out from the standard library This repository factors out an opinionated selection of internal packages and functionality from the Go standard library. Currently this consists mostly of packages and testing code from within the Go tool implementation. . Included are the following: . * dirhash: calculate hashes over directory trees the same way that the Go tool does. * goproxytest: a GOPROXY implementation designed for test use. * gotooltest: Use the Go tool inside test scripts (see testscript below). * imports: list of known architectures and OSs, and support for reading import statements. * modfile: read and write go.mod files while preserving formatting and comments. * module: module paths and versions. * par: do work in parallel. * semver: semantic version parsing. * testenv: information on the current testing environment. * testscript: script-based testing based on txtar files. * txtar: simple text-based file archives for testing. Reason for packaging: Required by hugo 0.60.0+
Re: Is there still a point in installing libgcrypt to /lib instead of /usr/lib
On Sat, 15 Feb 2020 at 21:24:38 +0100, Michael Biebl wrote: > While I think the underlying issue should be investigated (tbh the > thought that dpkg get's confused / its db corrupted so does not properly > clean up those old files is quite disconcerting), couldn't we just > switch the order of /lib and /usr/lib and make /usr/lib the preferred path? Maybe, but it could result in the opposite bug in some cases. Consider the SONAME libfoo.so.0, and assume the multiarch tuple is MA. 1. libfoo.so.0.1.2 is in /lib/MA 2. maintainer moves libfoo.so.0.2.3 from /usr/lib/MA to /lib/MA because some early-boot service needs libfoo.so.0 3. somehow libfoo.so.0.1.2 is not deleted during the upgrade 4. ldconfig creates libfoo.so.0 -> libfoo.so.0.1.2 in /lib/MA and libfoo.so.0 -> libfoo.so.0.2.3 in /usr/lib/MA (several years later) 5. now we have libfoo.so.0 -> libfoo.so.0.1.2 in /lib/MA and libfoo.so.0 -> libfoo.so.0.4.2 in /usr/lib/MA 6. we change ld.so.conf.d so that /usr/lib/MA is preferred over /lib/MA 7. programs that depend on libfoo0 (>= 0.4.2) get libfoo.so.0.1.2, and are broken, because symbols introduced since 0.1.2 are missing However, in many cases we might dodge that bullet in practice because the transition to multiarch happened between steps 4 and 5, and /usr/lib/MA and /lib/MA are both preferred over /usr/lib and /lib. For example, libdbus-1-3 transitioned from /usr/lib to /lib in 1.2.16-1, from /lib to /lib/MA in 1.4.12-3, and from /lib/MA to /usr/lib/MA in 1.13.10-1; so it might get a bug equivalent to #896019 if we don't reverse the priorities of /lib/MA and /usr/lib/MA, but it can't have the bug I describe above if we do reverse their priorities. smcv
Re: Is there still a point in installing libgcrypt to /lib instead of /usr/lib
On Sat, 15 Feb 2020 at 23:21:35 +0100, Guillem Jover wrote: > Doing a proper /usr-merged migration is what we should have done from > the beginning. I've been doing that with all the library packages I > maintain that were under /lib. That includes acl, attr, libaio, libbsd > and libmd, and I know others have been doing this too, so there's > plenty of precedent with this. To be clear, what Guillem means by "a proper /usr-merged migration" here is changing individual library packages, so that the path to their libraries that exists in the data.tar.* and in the dpkg database changes from for example /lib/MA/libfoo.so.0 to /usr/lib/MA/libfoo.so.0. This is not the same thing that a lot of other people mean by "the /usr merge". I think we have consensus that consolidating all static OS files into /usr (removing the distinction between /usr and the static parts of the root filesystem) is the route that Debian is taking. I think we do not have consensus on how that is to be achieved. I would be grateful if people who advocate transitioning individual packages, and people who consider the approach taken by usrmerge and debootstrap to be sufficient, could refer to their preferred route in a way that makes it clear which one they are advocating. Saying we should do a transition "properly" is tautologous - of course we should! - but when people disagree about what the proper way to do it is, it becomes an ambiguous recommendation that doesn't guide anyone to do the right thing. The approach that transitions individual packages solves some bugs (notably, if you ask dpkg which package owns /usr/lib/MA/libfoo.so.0, you get the right answer, which has a lot of desirable consequences). It also appears to *cause* some bugs. The ones I know about are: * packages that hard-code paths into /lib stop working on systems that have *not* undergone the usrmerge-style /usr merge, because /lib/MA/libfoo.so.0 no longer exists (for example see #950715 involving libgcc.so.1 and the gold linker); * there is a class of bugs on systems that have *not* undergone the usrmerge-style /usr merge, involving old libraries lingering in /lib/MA (see #949395 for a summary of the instances that I know about), which are very hard to debug because they are unreproducible, to do with the state of an individual system, and are related to upgrades that happened years in the past and whose logs expired long ago; * when paths migrate between package names and between paths at the same time, there can be undetected file conflicts on systems that *have* undergone the usrmerge-style /usr merge (for example see #950624, again in libgcc.so.1) The term "/usr merge" or "merged /usr" more commonly refers to making /usr/lib and /lib, /usr/bin and /bin, etc., *equivalent* (with symlinks /lib -> usr/lib, etc.), as implemented by the usrmerge package and debootstrap --merged-usr. In many other distributions, for example Fedora, there was a flag day at which merged /usr became mandatory. This makes various classes of bugs like #949395 and #950715 cease to exist: for example, it doesn't matter if /lib/MA/libfoo.so.0 is hard-coded somewhere, because that path still exists (realpath would resolve it to /usr/lib/MA/libfoo.so.0). (However, this can't solve everything: #950624 would still have been a bug if we had had a merged /usr flag-day.) In Debian we have (as usual) made life more difficult for ourselves by the /usr merge being optional, which means that in any transition or upgrade scenario, maintainers have to consider two cases: one where the system has undergone the /usr merge, and one where it has not. For example, #950624 only happens on systems that have undergone the /usr merge, while #950715 and #949395 only happen on systems that have not. Testing on any single system cannot detect all of these: to detect all the bugs, we have to try both configurations. smcv
Re: Y2038 - best way forward in Debian?
On Fri, Feb 14, 2020 at 10:56:47AM -0600, John Goerzen wrote: > > The thing that we have to remember is that an operating system is a > platform for running software. This problem is rather thorny, because: > > 1) Some software is provided in only binary form and cannot be > recompiled > > 2) Some software can be recompiled but makes assumptions about the size > of variables, may use int instead of time_t, and other assorted > messiness Cleanest would be to run such legacy programs inside some virtualization that also provides a virtual time long before 2038, using the last Debian release with the old architecture. > 3) Some software is going to break now, due to forward-looking time > calculations, and for others, it may be fine (or nearly so) even past > 2038 due to timekeeping being only ancillary to its purpose. For > instance, I have some old games that are binary-only and really don't > care what time it is. >... How confident are you that they work fine with negative time_t values? Functions like time(2) return (time_t)-1 on error. > John cu Adrian
Bug#951450: ITP: magit-todos -- show source file TODOs in Magit
Package: wnpp Owner: Lev Lamberov Severity: wishlist * Package name: magit-todos Version : 1.5.1 Upstream Author : Adam Porter * URL or Web page : http://github.com/alphapapa/magit-todos * License : GPL-3+ Programming Lang: Emacs Lisp Description : show source file TODOs in Magit This package displays keyword entries from source code comments and Org files in the Magit status buffer. Activating an item jumps to it in its file. By default, it uses keywords from `hl-todo', minus a few (like "NOTE").
Onnq IMO
Sent from Ron’s iPhone
Re: moving mg from salsa to github?
On Sat, 15 Feb 2020, Harald Dunkel wrote: > I am maintainer for mg, currently on salsa. Problem is, upstream > doesn't release tar balls anymore, but moved the code to github. > No tags. > > How can I tell Salsa? Should I drop the upstream and pristine-tar > branches on Salsa and integrate the repository on github? Would > you suggest to move the debian part to github instead? intel-microcode went through this same problem, although it had nothing to do with salsa. Suddenly: 1. I had a debian-side upstream branch with full upstream history based on tarballs that I had built based on tarball-only releases over the years (make that a decade). 2. I had a new upstream-side upstream branch that would soon accumulate history, based on their brand new github repo. And they were two entirely separate trees, of course. No common origin commit. I fixed that using a carefully planned, manually adjusted merge (read the MERGE STRATEGIES part of the manpage for "git merge", especially the "ours" and "theirs" of the recursive merge). That gave me an unified tree that would allow git to do the right thing as far as future merges, diffs and cherry-picks were concerned. Obviously, I ensured everything relevant from *both* side of the merges was present on the merge commit result (and dropped whatever I didn't want). The result tree contents MUST be semanthically compatible with the history it creates, or things will go sour really fast. >From them on, I just merge from github upstream on a topic branch, adjust whatever is needed, and then merge the topic branch to master. Please look at the intel-microcode's history *graph* to undestand what I mean. It is on salsa: https://salsa.debian.org/hmh/intel-microcode As for tarballs, it really depends. I'd either generate those using git based on the upstream's upstream branch, or use the ones from a tagged github release from upstream, if one exists. -- Henrique Holschuh
Bug#951459: ITP: sip5 -- Python bindings generator for C/C++ libraries
Package: wnpp Severity: wishlist Owner: Dmitry Shachnev * Package name: sip5 Version : 5.1.0 Upstream Author : Riverbank Computing Limited * URL : https://riverbankcomputing.com/software/sip/intro * License : SIP Programming Lang: C, Python Description : Python bindings generator for C/C++ libraries SIP is a collection of tools that makes it very easy to create Python bindings for C and C++ libraries. It was originally developed in 1998 to create PyQt, the Python bindings for the Qt toolkit, but can be used to create bindings for any C or C++ library. For example it is also used to generate wxPython, the Python bindings for wxWidgets. SIP comprises a set of build tools and a sip module. The build tools process a set of specification files and generates C or C++ code which is then compiled to create the bindings extension module. Several extension modules may be installed in the same Python package. Extension modules can be built so that they are are independent of the version of Python being used. In other words a wheel created from them can be installed with any version of Python starting with v3.5. sip4 already exists in Debian, this is an ITP for the next version, sip5. -- Dmitry Shachnev signature.asc Description: PGP signature
