Bug#951359: ITP: ocaml-fpath -- OCaml library for handling file system paths
Package: wnpp Severity: wishlist Owner: Ralf Treinen * Package name: ocaml-fpath Version : 0.7.2 Upstream Author : Daniel Bünzli * URL : https://erratique.ch/software/fpath * License : ISC Programming Lang: OCaml Description : OCaml library for handling file system paths Fpath is an OCaml module for handling file system paths with POSIX and Windows conventions. Fpath processes paths without accessing the file system and is independent from any system library. This package will be maintained in the debian-ocaml-maintainers team. This is a dependency for odoc.
Bug#951368: ITP: cargo-deny -- Cargo plugin to help you manage large dependency graphs
Package: wnpp Severity: wishlist Owner: Fabian Grünbichler * Package name: cargo-deny Version : 0.6.4 Upstream Author : Jake Shadle * URL : https://github.com/EmbarkStudios/cargo-deny * License : MIT or Apache-2.0 Programming Lang: Rust Description : Cargo plugin to help you manage large dependency graphs Allows checking for desired/undesired licenses, duplicate dependencies and unfixed CVEs in the graph of direct and transitive dependencies of a crate. Will be maintained via debcargo-conf / the Debian Rust team.
moving mg from salsa to github?
Hi folks, 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? Every helpful comment is highly appreciated Harri https://github.com/hboetes/mg https://salsa.debian.org/debian/mg
Re: moving mg from salsa to github?
On Sat, Feb 15, 2020 at 02:16:27PM +0100, Harald Dunkel wrote: > Hi folks, > > 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? > > Every helpful comment is highly appreciated > Harri > You could probably add the GitHub project as a new remote, then through gbp.conf (assuming you are using gbp) you can name a new branch as 'upstream'). Alternately, you could rename the current upstream branch as something else and then checkout the master branch from the GitHub remote as 'upstream' in your repository. You might also have to make some minor tweaks, but the above are the major steps. Regards, -Roberto -- Roberto C. Sánchez
Re: Announcing miniDebConf Montreal 2020 -- August 6th to August 9th 2020
On Sat, Feb 15, 2020 at 12:05:29AM -0500, Jerome Charaoui wrote: > > Following the announcement of the DebConf20 location, our desire to > participate became incompatible with our commitment toward the Boycott, > Divestment and Sanctions (BDS) campaign launched by Palestinian civil > society in 2005. Hence, many active Montreal-based Debian developpers, > along with a number of other Debian developpers, have decided not to > travel to Israel in August 2020 for DebConf20. > Would it be possible to not constantly air our personal political opinions and grievances on Debian lists? Especially as part of something that goes to an -announce list. If anything, this is harmful to Debian as a project. What would have been so difficult about something like "for those in the Debian community who for whatever reason cannot attend DebConf 2020 in Israel, there will be a mini-DebConf in Montreal" and so-on and so forth? Regards, -Roberto -- Roberto C. Sánchez
Re: moving mg from salsa to github?
On Sat, Feb 15, 2020 at 02:16:27PM +0100, Harald Dunkel wrote: > Hi folks, > > 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? Question seen. However I think the question doesn't an answer. Please revolt if you think otherwise. > Should I drop the upstream and pristine-tar > branches on Salsa and integrate the repository on github? No. > Would you suggest to move the debian part to github instead? No. > Every helpful comment is highly appreciated :-) The "problem" is "no more tarballs from upstream". (As in: The problem is NOT that upstream moved to some git repo server.) It is completely fine to keep all the Debian stuff at Salsa. IMHO boils the question of Original Poster down to What, or which version, should be packaged, when Upstream stopped doing releases? I see three possiblities: * Talk with Upstream about version numbering * Choose a version number scheme yourself * Ask for further advice > Harri > > https://github.com/hboetes/mg > https://salsa.debian.org/debian/mg > Groeten Geert Stappers -- Leven en laten leven
Re: moving mg from salsa to github?
On Sat, Feb 15, 2020 at 08:33:25AM -0500, Roberto C. Sánchez wrote: > On Sat, Feb 15, 2020 at 02:16:27PM +0100, Harald Dunkel wrote: > > Hi folks, > > > > 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? > > > > Every helpful comment is highly appreciated > > Harri > > > You could probably add the GitHub project as a new remote, then through > gbp.conf (assuming you are using gbp) you can name a new branch as > 'upstream'). Alternately, you could rename the current upstream branch > as something else and then checkout the master branch from the GitHub > remote as 'upstream' in your repository. You might also have to make > some minor tweaks, but the above are the major steps. Please state some examples where that is done. Groeten Geert Stappers -- Leven en laten leven
Re: moving mg from salsa to github?
fwiw, looking at the repo on github. There are tags. They're just dates, Ideally one would get an idea of what the tags are from upstream, but you could just git clone using a tag. Also github allows you to easily get a tarball given a tag: wget https://github.com/hboetes/mg/tarball/20180927 On Sat, Feb 15, 2020 at 8:36 AM Geert Stappers wrote: > On Sat, Feb 15, 2020 at 02:16:27PM +0100, Harald Dunkel wrote: > > Hi folks, > > > > 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? > > Question seen. > However I think the question doesn't an answer. > Please revolt if you think otherwise. > > > > Should I drop the upstream and pristine-tar > > branches on Salsa and integrate the repository on github? > > No. > > > Would you suggest to move the debian part to github instead? > > No. > > > > Every helpful comment is highly appreciated > :-) > > > The "problem" is "no more tarballs from upstream". > (As in: The problem is NOT that upstream moved to some git repo server.) > > It is completely fine to keep all the Debian stuff at Salsa. > > > IMHO boils the question of Original Poster down to > What, or which version, should be packaged, > when Upstream stopped doing releases? > > > I see three possiblities: > * Talk with Upstream about version numbering > * Choose a version number scheme yourself > * Ask for further advice > > > > Harri > > > > https://github.com/hboetes/mg > > https://salsa.debian.org/debian/mg > > > > > Groeten > Geert Stappers > -- > Leven en laten leven > >
Re: moving mg from salsa to github?
On Sat, Feb 15, 2020 at 02:41:59PM +0100, Geert Stappers wrote: > On Sat, Feb 15, 2020 at 08:33:25AM -0500, Roberto C. Sánchez wrote: > > On Sat, Feb 15, 2020 at 02:16:27PM +0100, Harald Dunkel wrote: > > > Hi folks, > > > > > > 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? > > > > > > Every helpful comment is highly appreciated > > > Harri > > > > > You could probably add the GitHub project as a new remote, then through > > gbp.conf (assuming you are using gbp) you can name a new branch as > > 'upstream'). Alternately, you could rename the current upstream branch > > as something else and then checkout the master branch from the GitHub > > remote as 'upstream' in your repository. You might also have to make > > some minor tweaks, but the above are the major steps. > > Please state some examples where that is done. > I'm not aware of any, else I would had given them. Regardless, gdp doesn't really care the source of its 'upstream' branch, nor its name if given in the configuration. Of course, if upstream is no longer releasing tarballs and Harald decides to track the GitHub upstream project as the 'upstream' branch in the repository where the Debian package is maintained, then the pristine-tar will probably have to go. But that seemed to be understood from the initial message. Either way, gbp is sufficiently flexible and configurable to be used in the way Harald describes. Regards, -Roberto -- Roberto C. Sánchez
Re: moving mg from salsa to github?
On 2/15/20 2:44 PM, Peter Silva wrote: fwiw, looking at the repo on github. There are tags. They're just dates, Ideally one would get an idea of what the tags are from upstream, but you could just git clone using a tag. Also github allows you to easily get a tarball given a tag: wget https://github.com/hboetes/mg/tarball/20180927 Thats the most recent version in Debian. AFAIR it was created before mg moved to github. I will try to contact upstream. Regards Harri
f...@packages.debian.org Re: moving mg from salsa to github?
On Sat, Feb 15, 2020 at 03:00:52PM +0100, Harald Dunkel wrote: > On 2/15/20 2:44 PM, Peter Silva wrote: > > fwiw, looking at the repo on github. There are tags. They're > > just dates, Ideally one would get an idea of what the tags are from > > upstream, but you could just git clone using a tag. Also github > > allows you to easily get a tarball given a tag: > > > > wget https://github.com/hboetes/mg/tarball/20180927 > > > > Thats the most recent version in Debian. > AFAIR it was created before mg moved to github. > > I will try to contact upstream. FWIW Consider to use email address m...@packages.debian.org for it. You, maintainer of package `mg` should have TWO copies of this email. One through the mailinglist. The other because I have m...@packages.debian.org CCed. As test. The idea is that it helps you to explain that you are maintainer of the package in Debian. Hope this helps. Groeten Geert Stappers -- Leven en laten leven
Re: moving mg from salsa to github?
Quoting Harald Dunkel (2020-02-15 14:16:27) > 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? > > Every helpful comment is highly appreciated > Harri > > https://github.com/hboetes/mg > https://salsa.debian.org/debian/mg Here are some example packages tracking git without release tagging: fonts-noto (cdbs with "classic" v4 watch file) json-js (mode=git watch file) jsbundle-web-interfaces (bundled tarballs with mode=git watch file) - 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
Bug#951373: ITP: ordered-map -- C++ insertion-order-preserving hash map and hash set
Package: wnpp Owner: Hilko Bengen Severity: wishlist * Package name: ordered-map Version : 0.8.1 Upstream Author : Tessil * URL or Web page : https://github.com/Tessil/ordered-map/releases * License : MIT Description : C++ insertion-order-preserving hash map and hash set This package is needed for pacakging Zeek 3.x (formerly known as Bro).
Bug#951376: ITP: scalene -- high-performance, high-precision CPU and memory profiler for Python
Package: wnpp Severity: wishlist Owner: Emmanuel Arias * Package name: scalene Version : 0.7.5 Upstream Author : Emery Berger * URL : https://github.com/emeryberger/scalene * License : Apache Programming Lang: Python Description : high-performance, high-precision CPU and memory profiler for Python Scalene is a high-performance CPU and memory profiler for Python that does a few things that other Python profilers do not and cannot do. It runs orders of magnitude faster than other profilers while delivering far more detailed information. . This package can be maintained under DPMT umbrella.
Re: moving mg from salsa to github?
On Sat, Feb 15, 2020 at 02:16:27PM +0100, Harald Dunkel wrote: > Problem is, upstream doesn't release tar balls anymore, but moved the > code to github. No tags. If you can get upstream to tag releases, then the "When upstream uses Git" section of the git-buildpackage manual will be useful: http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.upstream-git.html -- |)|/ Ryan Kavanagh | GPG: 4E46 9519 ED67 7734 268F |\|\ https://rak.ac | BD95 8F7B F8FC 4A11 C97A signature.asc Description: PGP signature
Re: moving mg from salsa to github?
On Sat, 2020-02-15 at 14:16 +0100, Harald Dunkel wrote: > Hi folks, > > 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? Yes. > Would you suggest to move the debian part to github instead? I think you should keep the packaging repository on Salsa, because Debian contributors generally have accounts there while some do not want to use (or are not allowed to use) Github. Ben. > Every helpful comment is highly appreciated > Harri > > https://github.com/hboetes/mg > https://salsa.debian.org/debian/mg -- Ben Hutchings Any sufficiently advanced bug is indistinguishable from a feature. signature.asc Description: This is a digitally signed message part
Re: Can Debian packaging changes require a CLA?
On Fri, 2020-02-14 at 15:46 +, Dimitri John Ledkov wrote: > Can a Debian Package Maintainer require CLA for accepting packaging > changes and distro patches to be uploaded into Debian itself? > > (case in point, debian maintainer & upstream wear the same hat, and > maintain upstream code & packaging on github.com, under a company org > with a CLA bot, rejecting debian/* merge proposals until CLA is > signed) > > I didn't find things specifically about this in the policy and/or in > the dfsg-faq and the three classic tests (desert island / dissident / > tentacles of evil) do not fit the bill quite right. The DFSG is about what rights owners allow downstream recipients to do, and not about whether or how they accept contributions back. And generally maintainers can follow their own policies for accepting or rejecting patches. So I don't think there's anything explicit that rules this out. Since NMUs are allowed in some circumstances, there can be an implicit conflict with such a policy, though as Matthew Garrett pointed out there are different kinds of CLA. The Developer's Certificate of Origin can be asserted by someone other than the original author, and I would feel confident in representing to upstream that a change made by another DD through an NMU was intended to be released under the project's stated license. But if an upstream project requires a CLA to be executed by every original contributor, I don't think it is viable to keep the Debian packaging in the upstream project's repository. Ben. -- Ben Hutchings Any sufficiently advanced bug is indistinguishable from a feature. signature.asc Description: This is a digitally signed message part
Re: moving mg from salsa to github?
On Sat, 2020-02-15 at 18:26 +0100, Geert Stappers wrote: > On Sat, Feb 15, 2020 at 05:02:03PM +, Ben Hutchings wrote: > > On Sat, 2020-02-15 at 14:16 +0100, Harald Dunkel wrote: > > > Hi folks, > > > > > > 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? > > > > Yes. > > Euh ... > > > > Would you suggest to move the debian part to github instead? > > > > I think you should keep the packaging repository on Salsa, because > > Debian contributors generally have accounts there while some do not > > want to use (or are not allowed to use) Github. > > I do read that as the above 'Yes.' should be a 'No.' I'm interpreting "integrate" as "merge from". If it means moving to Github, why would the *next* sentence say "move ... to github instead"? Ben. -- Ben Hutchings Any sufficiently advanced bug is indistinguishable from a feature. signature.asc Description: This is a digitally signed message part
Re: moving mg from salsa to github?
Hi Harald On Sat, Feb 15, 2020 at 02:16:27PM +0100, 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. This is nothing uncommon. > No tags. So this upstream doesn't make releases but only provides HEAD. > How can I tell Salsa? Salsa is a git hosting. It does not care. > Should I drop the upstream and pristine-tar > branches on Salsa _No_. They refer to Debian releases, not upstream releases. > integrate the repository on github? "Integrate"? > Would > you suggest to move the debian part to github instead? Are you upstream? git is git, regardless of where it is located. Sure, some git hosting services give you additional functionality. But not for this case Regards, Bastian -- There is a multi-legged creature crawling on your shoulder. -- Spock, "A Taste of Armageddon", stardate 3193.9
Is there still a point in installing libgcrypt to /lib instead of /usr/lib
Hello, afaict we are moving to a usrmerge setup, i.e. with /lib just a symlink to /usr/lib. So shouldn't packages start installing stuff to /usr/lib instead of /lib? I would like to do that for libgcrypt, since I would be able to shorten debian/rules by stopping to split stuff between /lib (.so) and /usr/lib (.a). TIA, cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' signature.asc Description: PGP signature
Re: moving mg from salsa to github?
On Sat, Feb 15, 2020 at 05:33:51PM +, Ben Hutchings wrote: > On Sat, 2020-02-15 at 18:26 +0100, Geert Stappers wrote: > > On Sat, Feb 15, 2020 at 05:02:03PM +, Ben Hutchings wrote: > > > On Sat, 2020-02-15 at 14:16 +0100, Harald Dunkel wrote: > > > > Hi folks, > > > > > > > > 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? > > > > > > Yes. > > > > Euh ... > > > > > > Would you suggest to move the debian part to github instead? > > > > > > I think you should keep the packaging repository on Salsa, because > > > Debian contributors generally have accounts there while some do not > > > want to use (or are not allowed to use) Github. > > > > I do read that as the above 'Yes.' should be a 'No.' > > I'm interpreting "integrate" as "merge from". If it means moving to > Github, why would the *next* sentence say "move ... to github instead"? To me is packaging having a copy of upstream and its tarball releases. Hence I don't understand the 'Yes.' on "Should I drop upstream an pristine-tar" Anyway: I do hope that Original Poster has its question answered. Groeten Geert Stappers -- Leven en laten leven
Re: Is there still a point in installing libgcrypt to /lib instead of /usr/lib
On Sat, 2020-02-15 at 18:31 +0100, Andreas Metzler wrote: > Hello, > > afaict we are moving to a usrmerge setup, i.e. with /lib just a > symlink to /usr/lib. So shouldn't packages start installing stuff to > /usr/lib instead of /lib? I would like to do that for libgcrypt, since > I would be able to shorten debian/rules by stopping to split stuff > between /lib (.so) and /usr/lib (.a). Since stretch, it's a requirement that any separate /usr is mounted by an initramfs before the normal init system is started: https://www.debian.org/releases/stretch/amd64/release-notes/ch-information.en.html#late-mounting-usr So although usrmerge is optional, I believe there is no need to install libraries under /lib except for the dynamic linkers (which the kernel loads using absolute paths). Ben. > TIA, cu Andreas -- Ben Hutchings Any sufficiently advanced bug is indistinguishable from a feature. signature.asc Description: This is a digitally signed message part
Re: Is there still a point in installing libgcrypt to /lib instead of /usr/lib
On 2020-02-15 18:29 +, Ben Hutchings wrote: > On Sat, 2020-02-15 at 18:31 +0100, Andreas Metzler wrote: >> Hello, >> >> afaict we are moving to a usrmerge setup, i.e. with /lib just a >> symlink to /usr/lib. So shouldn't packages start installing stuff to >> /usr/lib instead of /lib? I would like to do that for libgcrypt, since >> I would be able to shorten debian/rules by stopping to split stuff >> between /lib (.so) and /usr/lib (.a). > > Since stretch, it's a requirement that any separate /usr is mounted by > an initramfs before the normal init system is started: > https://www.debian.org/releases/stretch/amd64/release-notes/ch-information.en.html#late-mounting-usr > > So although usrmerge is optional, I believe there is no need to install > libraries under /lib except for the dynamic linkers (which the kernel > loads using absolute paths). True, but there seem to be a relatively high number of systems where an old unowned version of some library is lying around under /lib (possibly because the dpkg database became corrupted at some point and so dpkg forgot about the file; see the dpkg bug #949395), and when that library starts be installed under /usr/lib, this will trigger symbol lookup errors and the like. See #896019 and #948318 for examples. Cheers, Sven
Re: Is there still a point in installing libgcrypt to /lib instead of /usr/lib
On Feb 15, Sven Joachim wrote: > True, but there seem to be a relatively high number of systems where an > old unowned version of some library is lying around under /lib (possibly > because the dpkg database became corrupted at some point and so dpkg > forgot about the file; see the dpkg bug #949395), and when that library > starts be installed under /usr/lib, this will trigger symbol lookup > errors and the like. See #896019 and #948318 for examples. Somebody reported a similar problem about libcrypt.so.1, which moved from /lib/ (provided by libc) to /usr/lib/ (provided by libxcrypt). Since libcrypt.so.1 has been in /usr/lib/ for three months now without any other unexpected issues then I think that we can be very confident that there is no reason whatsoever to install anything outside of /usr anymore. -- ciao, Marco signature.asc Description: PGP signature
Re: moving mg from salsa to github?
On Feb 15, 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. I plan to do something like this for ppp, which now has a proper upstream git repository but no actual releases in a long time: mkdir /dev/shm/ppp/ cd /dev/shm/ppp rsync -aH .../ppp-2.4.7/ ppp-2.4.7/ cd ppp-2.4.7/ git branch -m upstream tarupstream git checkout tarupstream git remote add upstream https://github.com/paulusmack/ppp.git git fetch upstream git checkout remotes/upstream/master git switch -c upstream git merge tarupstream --allow-unrelated-histories git branch -d tarupstream git tag ppp-2.4.7+20191019 git checkout master git merge ppp-2.4.7+20191019 dch --preserve --version 2.4.7+20191019-1+1 "New upstream snapshot." cat << END > debian/gbp.conf [DEFAULT] upstream-tag = ppp-%(version)s pristine-tar = False compression = xz [pq] patch-numbers = False END gbp export-orig -- ciao, Marco signature.asc Description: PGP signature
Re: Is there still a point in installing libgcrypt to /lib instead of /usr/lib
Am 15.02.20 um 19:48 schrieb Sven Joachim: > True, but there seem to be a relatively high number of systems where an > old unowned version of some library is lying around under /lib (possibly > because the dpkg database became corrupted at some point and so dpkg > forgot about the file; see the dpkg bug #949395), and when that library > starts be installed under /usr/lib, this will trigger symbol lookup > errors and the like. See #896019 and #948318 for examples. 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? signature.asc Description: OpenPGP digital signature
Re: f...@packages.debian.org Re: moving mg from salsa to github?
On 2/15/20 3:14 PM, Geert Stappers wrote: > FWIW Consider to use email address m...@packages.debian.org for it. > >[...] > The idea is that it helps you to explain that you are maintainer > of the package in Debian. Hope this helps. So far I did not find a single upstream that was not able to understand a sentence like "Hi, my name is foo and I'm the Debian developer who is maintaining blubb in Debian". And if they fail to understand it... not sure if you should package their software. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Re: Is there still a point in installing libgcrypt to /lib instead of /usr/lib
On Sat, 2020-02-15 at 20:35:58 +0100, Marco d'Itri wrote: > On Feb 15, Sven Joachim wrote: > > True, but there seem to be a relatively high number of systems where an > > old unowned version of some library is lying around under /lib (possibly > > because the dpkg database became corrupted at some point and so dpkg > > forgot about the file; see the dpkg bug #949395), and when that library > > starts be installed under /usr/lib, this will trigger symbol lookup > > errors and the like. See #896019 and #948318 for examples. > Somebody reported a similar problem about libcrypt.so.1, which moved > from /lib/ (provided by libc) to /usr/lib/ (provided by libxcrypt). If the problem was with the new pathname disappearing, then that's just yet another instance of the usrmerge-via-symlinks collateral damage. Moving a pathname to an aliased directory across different binary packages can make the new pathname disappear depending on the unpack order. Because, if dpkg unpacks the package now owning the new pathname, and then unpacks the package that has stopped owning the old pathname, when it removes that, it will end up removing the aliased pathname and will not notice any Replaces takeover due to the directory aliasing. > Since libcrypt.so.1 has been in /usr/lib/ for three months now without > any other unexpected issues then I think that we can be very confident > that there is no reason whatsoever to install anything outside of /usr > anymore. Then the libcrypt package is broken on dist upgrade and can render usrmerge-via-symlinks systems unusable. Package doing a proper /usr-merge migration within the same binary package are of course perfectly fine everywhere, and also of course non-usrmerged systems are always fine. The irony in all this is that the usrmerge hack that got introduced to make the switch faster and easier, has been consistently making a proper /usr-merged switch more fragile and difficult… I need to create a wiki with the increasing list of issues and a big fat note stating that these broken deployments are unsupported by dpkg. Regards, Guillem
Re: Is there still a point in installing libgcrypt to /lib instead of /usr/lib
Hi! On Sat, 2020-02-15 at 18:31:32 +0100, Andreas Metzler wrote: > afaict we are moving to a usrmerge setup, i.e. with /lib just a > symlink to /usr/lib. So shouldn't packages start installing stuff to > /usr/lib instead of /lib? I would like to do that for libgcrypt, since > I would be able to shorten debian/rules by stopping to split stuff > between /lib (.so) and /usr/lib (.a). 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. Thanks, Guillem
Re: Is there still a point in installing libgcrypt to /lib instead of /usr/lib
Am 15.02.20 um 23:11 schrieb Guillem Jover: > On Sat, 2020-02-15 at 20:35:58 +0100, Marco d'Itri wrote: >> On Feb 15, Sven Joachim wrote: >>> True, but there seem to be a relatively high number of systems where an >>> old unowned version of some library is lying around under /lib (possibly >>> because the dpkg database became corrupted at some point and so dpkg >>> forgot about the file; see the dpkg bug #949395), and when that library >>> starts be installed under /usr/lib, this will trigger symbol lookup >>> errors and the like. See #896019 and #948318 for examples. > >> Somebody reported a similar problem about libcrypt.so.1, which moved >> from /lib/ (provided by libc) to /usr/lib/ (provided by libxcrypt). > > If the problem was with the new pathname disappearing, then that's just > yet another instance of the usrmerge-via-symlinks collateral damage. > > Moving a pathname to an aliased directory across different binary > packages can make the new pathname disappear depending on the unpack > order. Because, if dpkg unpacks the package now owning the new pathname, > and then unpacks the package that has stopped owning the old pathname, > when it removes that, it will end up removing the aliased pathname and > will not notice any Replaces takeover due to the directory aliasing. > >> Since libcrypt.so.1 has been in /usr/lib/ for three months now without >> any other unexpected issues then I think that we can be very confident >> that there is no reason whatsoever to install anything outside of /usr >> anymore. > > Then the libcrypt package is broken on dist upgrade and can render > usrmerge-via-symlinks systems unusable. Package doing a proper /usr-merge > migration within the same binary package are of course perfectly fine > everywhere, and also of course non-usrmerged systems are always fine. Those issues happen on non-usr-merged systems. signature.asc Description: OpenPGP digital signature
Re: Is there still a point in installing libgcrypt to /lib instead of /usr/lib
On Sat, 2020-02-15 at 23:27:08 +0100, Michael Biebl wrote: > Those issues happen on non-usr-merged systems. The one report against dpkg sure. I'm talking about the ones with disappearing pathnames, in case that was part of "similar". But if it was not, then libcrypt is still just broken on usrmerge-via-symlink systems, like libgcc-s1 was for a bit when it tried to do the same by moving directories across binary packages. But I guess I should not care much given that I consider those system broken already anyway… Regards, Guillem
Re: Is there still a point in installing libgcrypt to /lib instead of /usr/lib
On Feb 15, Guillem Jover wrote: > > Somebody reported a similar problem about libcrypt.so.1, which moved > > from /lib/ (provided by libc) to /usr/lib/ (provided by libxcrypt). > If the problem was with the new pathname disappearing, then that's just > yet another instance of the usrmerge-via-symlinks collateral damage. No: the problem was an old libcrypt.so.1 left in /lib/. This cannot have anything to do with merged-usr: if /lib/ and /usr/lib/ on this system were actually merged then it would not be possible to have two different libraries around. > The irony in all this is that the usrmerge hack that got introduced to The irony is that in your quest to fight usrmerge, which at this point has been the default for all new installs and obviously did not cause any major troubles, you ranted at lenght about something which does not appear to be a real-life problem (people tend to report bugs which break PAM and perl...). -- ciao, Marco signature.asc Description: PGP signature
Crossgrading support (was Re: Y2038 - best way forward in Debian?)
Adam Borowski wrote: >On Wed, Feb 12, 2020 at 06:10:53PM +, Steve McIntyre wrote: >> >> /me ponders - this could be a fun task for a GSoC/outreachy student to >> hack on, maybe? > >Prior art: > >* my unfinished https://github.com/kilobyte/crossgrade -- does a lot of > error checking and continue-after-problem, but currently stops after > crossgrading the essential set > >* stuff linked from https://wiki.debian.org/CrossGrading Ah, cool! >Problems: > >* crossgrades fail _badly_ in a hard to recover way if packages for the > two architectures come in different versions (including binNMUs). This > hurts especially if -ports archs are involved. Yup. Probably best done on top of a stable release, by default, to avoid the worst of this, >* arch-specific or local packages are not as bad but 1. crossgrade must > know what's safe to remove, 2. what should be left unchanged (and their > recursive deps unremoved), 3. there may be non-multiarchable packages > within 1. or 2.'s dependency chain Yup. So I think it would be good to have a tool which can work through the existing state of a system up-front and analyse what's likely to work or not. >* systemd can't handle being crossgraded (I'm a systemd hater, but same was > noticed by eg. anarcat and Simon Richter). On a minimal system it may > survive but usually it starts killing daemons (including X), unmounting > stuff, choking and forcing an unclean reboot, etc. This could be worked > around by: > ⢠switching to sysvinit > ⢠booting from a different media then chrooting to crossgrade (not for >ordinary users unless it's eg. scripted from d-i) > ⢠having a package bring a grub entry that boots with >init=/usr/sbin/crossgrade to do the thing? ACK. Booting in a *simple* state is likely to be key. -- Steve McIntyre, Cambridge, UK.st...@einval.com Armed with "Valor": "Centurion" represents quality of Discipline, Honor, Integrity and Loyalty. Now you don't have to be a Caesar to concord the digital world while feeling safe and proud.
Re: Y2038 - best way forward in Debian?
Hey John, John Goarzen wrote: >On Tue, Feb 04 2020, Steve McIntyre 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 Oh, absolutely. In that situation there's not a lot we can sensibly do, modulo telling people to run such things in a time-shifted VM. I'm more worried about making *our* software work in the future. >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 Nod. I'm sure we'll find quite a bit of that, and need to file (and maybe fix) those bugs. Hell, we're also likely to find some places where we won't be able to sensibly fix things. But it's better to know and document those places than not. >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. Yup. >This option #1 sounds like a significant effort (because not only would >we need two versions of libraries, but also of include files). But it >certainly passes the "correctness" test better than your option #2. Sure. It comes down to how long we think we can / want to spend on this. I'd *hope* that a lot of software *will* work correctly with a rebootstrap, but of course we know it won't be 100%. I'm concerned that we don't leave it too long to get on with fixing things - that will continue to build an ever-growing corpus of broken systems that people will need to deal with later. -- Steve McIntyre, Cambridge, UK.st...@einval.com Armed with "Valor": "Centurion" represents quality of Discipline, Honor, Integrity and Loyalty. Now you don't have to be a Caesar to concord the digital world while feeling safe and proud.
Re: Y2038 - best way forward in Debian?
anth...@derobert.net wrote: ... >Lastly, 64-bit time_t has been tested widely (e.g., on amd64). That's not >perfect of >course since 32-bit archs have smaller basic integer types, but likely a lot >less work >fixing the stray "int"s than adding epochs all over the place. > >PS: Debian-devel is likely the wrong place to redesign C/POSIX functions. +1000 -- Steve McIntyre, Cambridge, UK.st...@einval.com Armed with "Valor": "Centurion" represents quality of Discipline, Honor, Integrity and Loyalty. Now you don't have to be a Caesar to concord the digital world while feeling safe and proud.
Re: call for ftpmaster's transparency
Hello, On Mon 10 Feb 2020 at 04:29PM +11, Dmitry Smirnov wrote: > No. ITPs are opportunities to team up with others, not merely for de- > duplication. For many small packages there is simply no need for teaming up at the stage of uploading to NEW. > That might be a valid situation but nevertheless how much effort it is to > file an ITP?? Not much even if filing new ITP is not mandated. > But when ITP is there, then it could be referred to as "blocked by" or > "blocking" bug, it can have "affects" relationships with other packages, etc. I find it overly effortful. > Also you never know how long your package will stay in the NEW queue and > during this time lack of ITP could affect developers priorities. Well, I always look at the current NEW queue before packaging something. -- Sean Whitton signature.asc Description: PGP signature
Re: moving mg from salsa to github?
Hello, On Sat 15 Feb 2020 at 02:16PM +01, 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? Looks like there are upstream release tags, but if not, what I'd do is tag upstream commits with pseudo-upstream tags and then merge those to my packaging branch. For example if you want to upload the most recent commit at the time of writing, git remote add -f upstream https://github.com/hboetes/mg git tag -s upstream/0+git20200215.1.3992db3 3992db3 git merge upstream/0+git20200215.1.3992db3 dch -v0+git20200215.1.3992db3-1 New upstream release. -- Sean Whitton signature.asc Description: PGP signature
Re: moving mg from salsa to github?
Hello, On Sat 15 Feb 2020 at 06:45PM -07, Sean Whitton wrote: > git remote add -f upstream https://github.com/hboetes/mg > git tag -s upstream/0+git20200215.1.3992db3 3992db3 > git merge upstream/0+git20200215.1.3992db3 > dch -v0+git20200215.1.3992db3-1 New upstream release. ... and then `git deborig` when you want to build source packages. -- Sean Whitton signature.asc Description: PGP signature
Bug#951405: ITP: golang-github-yuin-goldmark-highlighting -- syntax highlighting extension for the goldmark Markdown parser
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-yuin-goldmark-highlighting Version : 0.0~git20191202.78f32c8-1 Upstream Author : Yusuke Inuzuka * URL : https://github.com/yuin/goldmark-highlighting * License : Expat Programming Lang: Go Description : syntax highlighting extension for the goldmark Markdown parser. goldmark-highlighting is an extension for the goldmark Markdown parser that adds syntax-highlighting to fenced code blocks. . goldmark-highlighting uses chroma as syntax highlighter. Reason for packaging: Needed by Hugo 0.60.0 and up
