Re: MBF: Packages which break with nocheck
El 13/4/25 a las 15:22, Simon McVittie escribió: I think there are two subtly different things that you could mean by "with nocheck": 1. DEB_BUILD_OPTIONS=nocheck, but no special build profiles - therefore build-dependencies are still installed 2. DEB_BUILD_OPTIONS=nocheck DEB_BUILD_PROFILES=nocheck - therefore build-dependencies are likely to be missing Ok, in the end there was a lot of overlap between those two, so I decided to report in a single bug the subset of (1) which also fails (2). In some future mass rebuild maybe I will try the nocheck build profile in full (not as a subset of DEB_BUILD_OPTIONS=nocheck). For reference, I've used this usertag for all the bugs (26 new and 3 old): https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian...@lists.debian.org;tag=ftbfs-nocheck-profile Thanks a lot.
Re: Bug#1094969: git linked with OpenSSL
On 4/16/25 12:34 PM, Henrik Ahlgren wrote: BTW, FSF considers Apache 2.0 as a good license and that "it's unfortunate that the Apache License 2.0 isn't compatible with some free software licenses like GPLv2". Compatibility with it was one important goal for GPLv3. So, this incompatibility was not never designed, it was just a mistake of an early free software license from a different era. But the crucial point here is that the git upstream is choosing not to correct that mistake by moving to GPLv3 (probably they don't like some other changes introduced) or giving another specific exception to linking with Apache 2.0. OpenPGP_0x8F53E0193B294B75.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Planning to remove team-based R packages from 32-bit and big-endian architectures.
On Wed, 16 Apr 2025 at 23:04:47 +0900, Charles Plessy wrote: If you need one of the team-maintained r-cran-* packages on a 32-bit or on a big endian architectures, which are not supported upstream, please contact me on the debian-r list and let's see how we can share the workload. It might be best to re-send this to debian-arm (representing the two 32-bit release architectures with a porter mailing list) and debian-s390 (representing the only big-endian release architecture). Possibly also debian-powerpc, although the big-endian versions of that are -ports anyway. (I don't expect that you will realistically get contributions from those architectures, but it seems polite to let them know.) smcv
Re: Planning to remove team-based R packages from 32-bit and big-endian architectures.
On 16 April 2025 at 18:31, Paul Gevers wrote: | I haven't checked why they are there, but there are several packages in | the key package set [1]. I would be good to check beforehand what | happens if they are removed on those architectures. I think it's best to | assume for now that you can't remove them at this stage of the release. | | [1] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi That appears to be a different set of packages. It is comprised entirely of packages that the meta package "r-recommended" depends upon. [ The R 'engine' is provided by package "r-base-core" which can run on its own, the wider package "r-base" also depends on "r-recommended" bringing these in. It is a set of packages commonly used with R and curatedby upstream, that is by the upstream R Core team. ] These packages are all maintained by me, and they build fine under i386 etc. So no issue there as far as I can tell. Cheers, Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1103353: ITP: libpwm -- library and tools for interacting with Linux PWM devices
Package: wnpp Severity: wishlist Owner: Uwe Kleine-König X-Debbugs-Cc: debian-devel@lists.debian.org, uklei...@debian.org * Package name: libpwm Upstream Contact: Uwe Kleine-König * License : LGPL + 0BSD Programming Lang: C Description : library and tools for interacting with Linux PWM devices For now the library and tools are mainly development helpers and test tools for writing and maintaining Linux PWM drivers. The library can also be used by applications to simplify controlling a PWM device. Traditionally PWMs are controlled from userspace via /sys/class/pwm, but an alternative kernel interface is currently developed that provides faster and more versatile operation. libpwm can handle both backends and transparently abstracts their API. The library is licensed under LGPL to be usable by any application, the trivial tools are 0BSD to serve also as example code for integration into bigger applications. There is no release available of libpwm yet, but this will be addressed once the kernel bits are set in stone. Best regards Uwe
Re: Bug#1094969: git linked with OpenSSL
Le Wed, Apr 16, 2025 at 08:39:18AM +0200, Ansgar 🙀 a écrit : > Hi, > > On Wed, 2025-04-16 at 07:27 +0200, Simon Josefsson wrote: > > Yes that seems likely. I think that the decision in other distributions > > may have had more to do with aligning interests with organization who > > fund them, though. > > This is moving into conspiracy theory territory... We can as well > suspect reptiloids behind this. This is uncalled for. Saying that Fedora is influenced by RedHat for example is not a conspiracy theory. Debian has traditionally adopted a stricter approach to licenses than other distributions. > Debian has always allowed GPL-2-only code linked against GPL-3+-only > libraries such as the libstdc++ or GCC runtime libraries. (You ignore > that libraries aside of OpenSSL exist.) Note that libstdc++ and GCC runtime libraries are covered by the GCC Runtime Library Exception which is different from the system library exception. Cheers, Bill.
Re: Planning to remove team-based R packages from 32-bit and big-endian architectures.
Hi Dirk, On 16-04-2025 18:55, Dirk Eddelbuettel wrote: | [1] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi That appears to be a different set of packages. The packages spotted in the original list, I assume you're talking about all of them except maybe cantor and vtk9? boot: r-recommended depends r-cran-boot cantor: kdeedu depends cantor cluster: r-recommended depends r-cran-cluster codetools: r-recommended depends r-cran-codetools dh-r: boot build-depends dh-r foreign: r-recommended depends r-cran-foreign kernsmooth: r-recommended depends r-cran-kernsmooth lattice: r-recommended depends r-cran-lattice mgcv: r-recommended depends r-cran-mgcv nlme: r-recommended depends r-cran-nlme r-cran-class: r-recommended depends r-cran-class r-cran-mass: r-recommended depends r-cran-mass r-cran-nnet: r-recommended depends r-cran-nnet r-cran-spatial: r-recommended depends r-cran-spatial rmatrix: r-recommended depends r-cran-matrix rpart: r-recommended depends r-cran-rpart survival: r-recommended depends r-cran-survival vtk9: opencv build-depends libvtk9-dev Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: MBF: Packages which break with nocheck
Hi Santiago, On 16-04-2025 15:04, Santiago Vila wrote: For reference, I've used this usertag for all the bugs (26 new and 3 old): https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian- q...@lists.debian.org;tag=ftbfs-nocheck-profile In one of the reports I read this: """ * When a package is built with the nocheck profile, it means: - DEB_BUILD_OPTIONS=nocheck (the tests should be skipped during the build) - DEB_BUILD_PROFILES=nocheck (Build-Depends marked are not installed) - The contents of the package is allowed to be different than normal """ I don't think that's true. I was very much under the impression that with the build profile nocheck all binaries have to be build and the content has to be the same. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Planning to remove team-based R packages from 32-bit and big-endian architectures.
Hi, On 16-04-2025 16:04, Charles Plessy wrote: If you need one of the team-maintained r-cran-* packages on a 32-bit or on a big endian architectures, which are not supported upstream, please contact me on the debian-r list and let's see how we can share the workload. Otherwise I will start the process next week, assuming silent approval. The alternative is to lose a lot of r-cran-* packages from amd64 as well. I haven't checked why they are there, but there are several packages in the key package set [1]. I would be good to check beforehand what happens if they are removed on those architectures. I think it's best to assume for now that you can't remove them at this stage of the release. Paul [1] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi OpenPGP_signature.asc Description: OpenPGP digital signature
Re: MBF: Packages which break with nocheck
On Wed, 16 Apr 2025 at 18:40:00 +0200, Paul Gevers wrote: In one of the reports I read this: """ * When a package is built with the nocheck profile, it means: - DEB_BUILD_OPTIONS=nocheck (the tests should be skipped during the build) - DEB_BUILD_PROFILES=nocheck (Build-Depends marked are not installed) - The contents of the package is allowed to be different than normal """ I don't think that's true. I was very much under the impression that with the build profile nocheck all binaries have to be build and the content has to be the same. The definition of the nocheck build profile on https://wiki.debian.org/BuildProfileSpec agrees with Paul's impression. I think it's reasonable for Santiago's mass-rebuild not to verify whether those desired properties were actually true (to verify them, he would have had to build the package twice, with and without nocheck, defeating the purpose of wanting to skip potentially flaky or slow build-time tests) but it would be better if future bug reporting for this scenario didn't encourage maintainers to implement nocheck incorrectly. So perhaps instead of The contents of the package is allowed to be different than normal the bug template should be more like The contents of the resulting package are meant to be identical to the package produced by a normal build, but this was not checked during this particular mass-rebuild or something along those lines? smcv
Planning to remove team-based R packages from 32-bit and big-endian architectures.
Hi all, let's be realistic, the r-cran-* packages team-maintained by me and others are not in a good shape. And given their complex net of cross-dependencies, there is the risk of removing a large number of them from Trixie before the release. When I check the UDD maintainer dasboard to set my priorities, I am distracted by issues related to the i386 and s390x platforms. For the first, I am not convinced that we have users that need us to ship r-cran-* packages in Trixie. For s390x, well, the popcon score is just 10… I do not believe that we will be able to fix everything on time, and I want to move the less important issues out of the way. We have a script (routine-update) that clones the source package repo from Salsa, updates debian/control, builds the package, prepares a source-only upload and a command to push the changes to Salsa. It has a --64 option that injects architecture-is-64-bit in the build depends and I will add a --little-endian one that will inject architecture-is-little-endian. After uploading the changes, I will then ask the FTP team to remove the team-maintained r-cran-* packages and all their reverse-dependencies from the excluded architectures. I have added a DD list that tries to predict the potentially affected packages. Please note that there are false positives, as I generated it with dak rm -Rn r-base for simplicity, but I am not proposing to touch r-base or the r-cran packages managed by Dirk. The vast majority of the affected dependencies are maintained by the Debian Med and Debian Science lists, which I have CCed. If you need one of the team-maintained r-cran-* packages on a 32-bit or on a big endian architectures, which are not supported upstream, please contact me on the debian-r list and let's see how we can share the workload. Otherwise I will start the process next week, assuming silent approval. The alternative is to lose a lot of r-cran-* packages from amd64 as well. Have a nice day, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://fediscience.org/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy Alba Crespi r-cran-data.table (U) r-cran-fastmatch (U) r-cran-nmf (U) r-cran-nnls (U) r-cran-phangorn (U) r-cran-pkgmaker (U) r-cran-registry (U) r-cran-rngtools (U) Andreas Tille assemblytics (U) bio-tradis (U) dh-r (U) ea-utils (U) libsbml (U) libvcflib (U) mapdamage (U) node-shiny-server (U) paleomix (U) picard-tools (U) pique (U) qcumber (U) r-bioc-affy (U) r-bioc-affyio (U) r-bioc-all (U) r-bioc-altcdfenvs (U) r-bioc-annotate (U) r-bioc-annotationdbi (U) r-bioc-annotationfilter (U) r-bioc-annotationhub (U) r-bioc-aroma.light (U) r-bioc-ballgown (U) r-bioc-biobase (U) r-bioc-biocbaseutils (U) r-bioc-biocfilecache (U) r-bioc-biocgenerics (U) r-bioc-biocio (U) r-bioc-biocparallel (U) r-bioc-biocstyle (U) r-bioc-biocversion (U) r-bioc-biomart (U) r-bioc-biomformat (U) r-bioc-biostrings (U) r-bioc-biovizbase (U) r-bioc-bladderbatch (U) r-bioc-bsgenome (U) r-bioc-bsseq (U) r-bioc-chemminer (U) r-bioc-cner (U) r-bioc-complexheatmap (U) r-bioc-consensusclusterplus (U) r-bioc-cummerbund (U) r-bioc-decontam (U) r-bioc-decoupler (U) r-bioc-degreport (U) r-bioc-densvis (U) r-bioc-deseq (U) r-bioc-deseq2 (U) r-bioc-destiny (U) r-bioc-dirichletmultinomial (U) r-bioc-dss (U) r-bioc-ebseq (U) r-bioc-edaseq (U) r-bioc-edger (U) r-bioc-ensembldb (U) r-bioc-fmcsr (U) r-bioc-genefilter (U) r-bioc-genelendatabase (U) r-bioc-genomeinfodb (U) r-bioc-genomicalignments (U) r-bioc-genomicfeatures (U) r-bioc-genomicranges (U) r-bioc-glmgampoi (U) r-bioc-go.db (U) r-bioc-gosemsim (U) r-bioc-goseq (U) r-bioc-graph (U) r-bioc-gviz (U) r-bioc-hilbertvis (U) r-bioc-hsmmsinglecell (U) r-bioc-hypergraph (U) r-bioc-ihw (U) r-bioc-interactivedisplaybase (U) r-bioc-ioniser (U) r-bioc-iranges (U) r-bioc-keggrest (U) r-bioc-limma (U) r-bioc-lpsymphony (U) r-bioc-makecdfenv (U) r-bioc-matrixgenerics (U) r-bioc-metagenomeseq (U) r-bioc-metapod (U) r-bioc-monocle (U) r-bioc-multtest (U) r-bioc-mutationalpatterns (U) r-bioc-pcamethods (U) r-bioc-pfamanalyzer (U) r-bioc-phyloseq (U) r-bioc-preprocesscore (U) r-bioc-protgenerics (U) r-bioc-purecn (U) r-bioc-pwmenrich (U) r-bioc-qvalue (U) r-bioc-rcpi (U) r-bioc-rgsepd (U) r-bioc-rhdf5 (U) r-bioc-rhdf5lib (U) r-bioc-rhtslib (U) r-bioc-rots (U) r-bioc-rsamtools (U) r-bioc-rtracklayer (U) r-bioc-rwikipathways (U) r-bioc-s4arrays (U) r-bioc-s4vectors (U) r-bioc-saturn (U) r-bioc-savr (U) r-bioc-scaledmatrix (U) r-bioc-scut
I cannot upload since yesterday
Hello, anyone else has the same problem as me? I've been trying to do an upload since yesterday night but it keeps failing. Uploading fortunes-it_2.14-1_amd64.changes: 421 Data timeout. Reconnect. Sorry. Is it just me? -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei https://ltworf.codeberg.page/ signature.asc Description: This is a digitally signed message part.
Re: I cannot upload since yesterday
On Wed, Apr 16, 2025 at 04:08:14PM +0200, Salvo Tomaselli wrote: > Hello, > > anyone else has the same problem as me? I've been trying to do an upload > since > yesterday night but it keeps failing. > > Uploading fortunes-it_2.14-1_amd64.changes: 421 Data timeout. Reconnect. > Sorry. > > Is it just me? I uploaded on Monday using the ssh-upload target. Have you tried that one? Regards, -Roberto -- Roberto C. Sánchez
Re: MBF: Packages which break with nocheck
On Wed, 16 Apr 2025 at 19:59:47 +0200, Santiago Vila wrote: I wish reproducible-builds people would activate DEB_BUILD_OPTIONS=nocheck for the second build https://bugs.debian.org/786644 smcv
Re: MBF: Packages which break with nocheck
El 16/4/25 a las 18:52, Simon McVittie escribió: the bug template should be more like The contents of the resulting package are meant to be identical to the package produced by a normal build, but this was not checked during this particular mass-rebuild or something along those lines? Yes, sorry, I'll change the template and will add extra information to the already submitted bugs. For some reason I believed having a different package contents was allowed in one case but not in the other, when it's never allowed. My fault. I wish reproducible-builds people would activate DEB_BUILD_OPTIONS=nocheck for the second build, I think it would help. I don't think anybody will use that as an excuse to file more RC bugs. Thanks.
Re: Bug#1094969: git linked with OpenSSL
Hi, On Wed, 2025-04-16 at 17:12 +, Bill Allombert wrote: > Le Wed, Apr 16, 2025 at 08:39:18AM +0200, Ansgar 🙀 a écrit : > > > Debian has always allowed GPL-2-only code linked against GPL-3+-only > > libraries such as the libstdc++ or GCC runtime libraries. (You ignore > > that libraries aside of OpenSSL exist.) > > Note that libstdc++ and GCC runtime libraries are covered by the > GCC Runtime Library Exception which is different from the system > library exception. How is that relevant? Note that (a) the runtime exception doesn't allow you to distribute the source for libstdc++ under GPL-2-compatible terms which would be required by the GPL-2-licensed software if one claims the system library exception does not apply. Otherwise: assume the runtime exception does so for all licenses, then it would trivially allow to distribute the libstdc++ source under proprietary licenses and one could just use a permissive license from the start instead of GPL-3+-with-limited-extra-permissions. (b) The OpenSSL license has a runtime library exception "built in" as it doesn't require libraries linking it to be distributed under similar terms as OpenSSL to begin with. So if it was relevant, the OpenSSL problem would be solved too. (And proprietary operating system vendors could just grant themselves an exception too if they wanted to distributed GPL-2 programs as part of the operating system.) Ansgar
Re: MBF: Packages which break with nocheck
Simon wrote: it would be better if future bug reporting for this scenario didn't encourage maintainers to implement nocheck incorrectly. You are absolutely right and I apologize for my mistake. Not just future but also *present*, so I've now added a clarification note to all the bugs I reported before. Thanks.
Re: Bug#1094969: git linked with OpenSSL
Henrik Ahlgren writes: > Simon Josefsson writes: > >> I think the idea behind the "proprietary system library" GPL exception >> is to make it possible to distribute GPL binaries linked to non-free >> system libraries on systems where that is pretty much unavoidable, e.g. >> system libraries on AIX, IRIX etc. The exception is that you are not >> required to distribute source code for the non-free system libraries: > > I feel it is important to remember that the GPL v2 was released in June > 1991. This was the era of proprietary UNIX, and the concept of a > (GNU/)Linux distribution, or the Linux kernel as a serious project, had > yet to emerge. Ian Murdoch founded Debian in 1993. Sure. But the concept of non-free system libraries is still common and the exception is applicable to these situations. Compare how Homebrew can distribute GPLv2 binaries linked to system libraries on macOS without having to distribute source code for those system libraries. > BTW, FSF considers Apache 2.0 as a good license and that "it's > unfortunate that the Apache License 2.0 isn't compatible with some free > software licenses like GPLv2". Compatibility with it was one important > goal for GPLv3. So, this incompatibility was not never designed, it was > just a mistake of an early free software license from a different era. That would be a good argument for git to use GPLv3 from 2007 instead of older GPLv2. I don't think that will happen, so we are stuck with GPLv2 for git, and the consequences of that decision. > I believe that the term "system library" lacks significant meaning in an > operating system like Debian. I think that I agree with this. System libraries were intended for things outside of the collection of work that you are distributing, such as non-free system libraries on proprietary Unix. The comparable element for Debian would be the UEFI boot loader or BIOS software. But if this is the case, it seems you cannot invoke the GPL exception? It is only valid for linking to something that qualify as a system library. If OpenSSL in Debian isn't a system library, there is no exception that allows linking. > One could argue that all libraries in Debian qualify as "system > libraries". Yes, I think that could also be reasonable. However I think this interpretation fails the "unless that component itself accompanies the executable" part of the GPLv2 system library exception: However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. All this said, I think primarily the assumption that other distributions made is that Linus won't sue to defend his GPLv2 copyright in Linux and isn't likely to do so for Git either. That assumption works less well for other copyright holders that may be more interested in defending their rights. /Simon signature.asc Description: PGP signature
Re: Debian Project Leader election 2025: Second call for votes
On Sat, Apr 12, 2025 at 09:09:25AM +0200, Debian Project Secretary - Kurt Roeckx wrote: > - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > 7066677e-e899-4143-af5e-710364fc2673 > [2] Choice 1: Gianfranco Costamagna > [2] Choice 2: Julian Andres Klode > [1] Choice 3: Andreas Tille > [1] Choice 4: Sruthi Chandran > [3] Choice 5: None Of The Above > - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- signature.asc Description: PGP signature
Re: Bug#1094969: git linked with OpenSSL
Pirate Praveen writes: > But the crucial point here is that the git upstream is choosing not to > correct that mistake by moving to GPLv3 (probably they don't like some > other changes introduced) or giving another specific exception to > linking with Apache 2.0. Well, Torvalds founded Git, and it is well known that he likes GPLv2 and dislikes v3. Apparently he is still a major copyright holder, even after handing over the project maintenance to Junio Hamano very early. And how many copyright holders are involved in the project? It might be permanently stuck to v2, much like the Linux kernel, which is now practically impossible to change licenses. Interestingly, the COPYING file in the Git tree states the following (https://github.com/git/git/blob/master/COPYING): Note that the only valid version of the GPL as far as this project is concerned is _this_ particular version of the license (ie v2, not v2.2 or v3.x or whatever), unless explicitly otherwise stated. HOWEVER, in order to allow a migration to GPLv3 if that seems like a good idea, I also ask that people involved with the project make their preferences known. In particular, if you trust me to make that decision, you might note so in your copyright message, ie something like This file is licensed under the GPL v2, or a later version at the discretion of Linus. might avoid issues. But we can also just decide to synchronize and contact all copyright holders on record if/when the occasion arises. Linus Torvalds
Re: Bug#1094969: git linked with OpenSSL
On 16.04.25 09:46, Henrik Ahlgren wrote: But we can also just decide to synchronize and contact all copyright holders on record if/when the occasion arises. Linus Torvalds should have known better than to be *that* optimistic. The number of such notices might serve as a rough indicator for how many people read such license files in the first place. (Spoiler: almost nobody.) -- -- regards -- -- Matthias Urlichs BEGIN:VCARD VERSION:4.0 N:Urlichs;Matthias;;; NICKNAME:Smurf EMAIL;PREF=1:matth...@urlichs.de TEL;TYPE=work;VALUE=TEXT:+49 911 59818 0 URL;TYPE=home:https://matthias.urlichs.de END:VCARD OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Bug#1094969: git linked with OpenSSL
On 16.04.25 07:27, Simon Josefsson wrote: I think the idea behind the "proprietary system library" GPL exception is to make it possible to distribute GPL binaries linked to non-free system libraries on systems where that is pretty much unavoidable, which, if you remove the "proprietary" and "non-free" wording which was unavoidable when the GPL was written but isn't nowadays, is exactly what we have here: it's pretty much unavoidable for nontrivial programs to somehow link to libraries with "incompatible" licenses. I thus move that we declare every library that supplies basic features (nowadays SSL certainly counts as such) to a widely disparate cabal of applications (ditto) to be a System Library. *Nobody* is going to go after Debian with a demand to stop doing such linking, much less demand compensation of any damages. If anybody ever does, well, we can discuss how to fix the problem then, **along with pretty much every other distro out there**. This is not a Debian specific problem. Going out of our way to pro-actively kowtow[1] to barely-understood legalese (we all are not lawyers, up to and including the FTP team) is not The Way. Neither is crippling some features of git, or whichever else program du jour has this problem. NB no it's not possible to re-license git to GPLv3. That'd be only slightly less difficult as re-licensing the Linux kernel. [1] "to show obsequious deference"* * -- -- mit freundlichen Grüßen -- -- Matthias Urlichs BEGIN:VCARD VERSION:4.0 N:Urlichs;Matthias;;; NICKNAME:Smurf EMAIL;PREF=1:matth...@urlichs.de TEL;TYPE=work;VALUE=TEXT:+49 911 59818 0 URL;TYPE=home:https://matthias.urlichs.de END:VCARD OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Planning to remove team-based R packages from 32-bit and big-endian architectures.
On 16 April 2025 at 19:24, Paul Gevers wrote: | Hi Dirk, | | On 16-04-2025 18:55, Dirk Eddelbuettel wrote: | > | [1] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi | > | > That appears to be a different set of packages. | | | The packages spotted in the original list, I assume you're talking about | all of them except maybe cantor and vtk9? | boot: r-recommended depends r-cran-boot | cantor: kdeedu depends cantor | cluster: r-recommended depends r-cran-cluster | codetools: r-recommended depends r-cran-codetools | dh-r: boot build-depends dh-r | foreign: r-recommended depends r-cran-foreign | kernsmooth: r-recommended depends r-cran-kernsmooth | lattice: r-recommended depends r-cran-lattice | mgcv: r-recommended depends r-cran-mgcv | nlme: r-recommended depends r-cran-nlme | r-cran-class: r-recommended depends r-cran-class | r-cran-mass: r-recommended depends r-cran-mass | r-cran-nnet: r-recommended depends r-cran-nnet | r-cran-spatial: r-recommended depends r-cran-spatial | rmatrix: r-recommended depends r-cran-matrix | rpart: r-recommended depends r-cran-rpart | survival: r-recommended depends r-cran-survival | vtk9: opencv build-depends libvtk9-dev Corret. Also, dh-r is only needed at build-time. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Re: Bug#1094969: git linked with OpenSSL
Simon Josefsson writes: > I think the idea behind the "proprietary system library" GPL exception > is to make it possible to distribute GPL binaries linked to non-free > system libraries on systems where that is pretty much unavoidable, e.g. > system libraries on AIX, IRIX etc. The exception is that you are not > required to distribute source code for the non-free system libraries: I feel it is important to remember that the GPL v2 was released in June 1991. This was the era of proprietary UNIX, and the concept of a (GNU/)Linux distribution, or the Linux kernel as a serious project, had yet to emerge. Ian Murdoch founded Debian in 1993. BTW, FSF considers Apache 2.0 as a good license and that "it's unfortunate that the Apache License 2.0 isn't compatible with some free software licenses like GPLv2". Compatibility with it was one important goal for GPLv3. So, this incompatibility was not never designed, it was just a mistake of an early free software license from a different era. https://www.fsf.org/blogs/licensing/new-license-recommendations-guide I believe that the term "system library" lacks significant meaning in an operating system like Debian. One could argue that all libraries in Debian qualify as "system libraries".
