Re: A proposal for improving transparency of the FTP NEW process
Gert Wollny writes: > Am Freitag, den 02.03.2018, 17:49 +0100 schrieb Philip Hands: >> Gert Wollny writes: >> >> > Am Freitag, den 02.03.2018, 14:01 +0100 schrieb Iustin Pop: >> > > >> > > How do you (we) know the package indeed is DFSG-compliant, if >> > > there >> > > is no license information? If upstream cannot bother to provide >> > > headers, how do we know the code is indeed licenced under the >> > > claimed >> > > licence? >> > > Etc. >> > > Note: I haven't looked at the package. Maybe I misunderstand the >> > > situation… >> > >> > The information is all there big parts of it just can't be >> > automatically extracted (mostly the copyright information), >> >> Would you be so kind as to cite some examples of copyright >> information that is there but not automatically extractable, just so >> that we can get an idea of what you have in mind? > > Sspecifically in vtk7 there are two main issues, one is that in nearly > all files the main copyright header is > > Copyright (c) Ken Martin, Will Schroeder, Bill Lorensen > All rights reserved. > See Copyright.txt or http://www.kitware.com/Copyright.htm for > details. > > This software is distributed WITHOUT ANY WARRANTY; without even > the implied warranty of MERCHANTABILITY or FITNESS FOR A ARTICULAR > PURPOSE. See the above copyright notice for more information. > > Which means licensecheck will report an unknown license, While licensecheck might not be able to do that right now, it is clear that it would be trivial to automatically detect that text, which is why I asked. Perhaps it's more work than licensecheck, or doesn't suit your requirements, but there is also license-reconcile. license-reconcile lets you add rules to deal with things that it doesn't understand out of the box: http://git.hands.com/?p=freeswitch.git;a=blob;f=debian/license-reconcile.yml;h=0e40cba01eeb67f82d18ca8f11210271848d0549;hb=refs/heads/copyright2 (as you can see, freeswitch is quite a jumble when it comes to copyright) Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: What can Debian do to provide complex applications to its users?
Le mardi, 27 février 2018, 14.13:41 h CET Didier 'OdyX' Raboud a écrit : > tl;dr: a new package format is needed, with a new non-suite-specific > repository is needed to bring the Debian added-value to these ecosystems. FTR, my current line of thought and understanding is that guix or nix do pretty much what is needed here, and it would be silly to start something from scratch. I plan to spend some brain time playing with guix and report back; I'm aware of: * https://bugs.debian.org/850644 for guix * https://bugs.debian.org/877019 for nix * Diane Trout's efforts 2 years ago on https://github.com/detrout/debian-guix Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Unit tests for debconf
Hi,
I was wondering if there was a way to mock the db_{get,set,input}
framework to do unit testing of my shell scripts. Does anyone has some
pointers to some docs, or any piece of software doing that?
Cheers,
Thomas Goirand (zigo)
Bug#892056: ITP: r-cran-emmeans -- GNU R estimated marginal means, aka least-squares means
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-cran-emmeans Version : 1.1.2 Upstream Author : Russell Lenth * URL : https://cran.r-project.org/package=emmeans * License : GPL Programming Lang: GPL Description : GNU R estimated marginal means, aka least-squares means Obtain estimated marginal means (EMMs) for many linear, generalized linear, and mixed models. Compute contrasts or linear functions of EMMs, trends, and comparisons of slopes. Plots and compact letter displays. Least-squares means are discussed, and the term "estimated marginal means" is suggested, in Searle, Speed, and Milliken (1980) Population marginal means in the linear model: An alternative to least squares means, The American Statistician 34(4), 216-221 . Remark: This package is needed to upgrade r-cran-afex to the latest upstream version. It will be maintained by the r-pkg team at https://salsa.debian.org/r-pkg-team/r-cran-emmeans
Re: What can Debian do to provide complex applications to its users?
Hello, On Sun, Mar 04 2018, Didier 'OdyX' Raboud wrote: > Le mardi, 27 février 2018, 14.13:41 h CET Didier 'OdyX' Raboud a >écrit : >> tl;dr: a new package format is needed, with a new non-suite-specific >> repository is needed to bring the Debian added-value to these >> ecosystems. > > FTR, my current line of thought and understanding is that guix or nix > do pretty much what is needed here, and it would be silly to start > something from scratch. > > I plan to spend some brain time playing with guix and report back; I'm > aware of: > > * https://bugs.debian.org/850644 for guix > * https://bugs.debian.org/877019 for nix > * Diane Trout's efforts 2 years ago on > https://github.com/detrout/debian-guix AIUI the guix repositories care more about including only free software than the nix repositories do. That might be a reason for us to prefer guix. Thank you for investigating these options! -- Sean Whitton signature.asc Description: PGP signature
Re: Unit tests for debconf
Hi Zigo,
On 04-03-18 18:02, Thomas Goirand wrote:
> I was wondering if there was a way to mock the db_{get,set,input}
> framework to do unit testing of my shell scripts. Does anyone has some
> pointers to some docs, or any piece of software doing that?
If you learn about this, I'd like to hear. In dbconfig-common, I do
testing without mocking. I use pre-seeding to change the answers given
by debconf.
Paul
signature.asc
Description: OpenPGP digital signature
Re: A proposal for improving transparency of the FTP NEW process
On 03/02/2018 01:00 PM, Gert Wollny wrote: > Since ftp-master also sometimes sends messages like "I let it pass for > now, but please fix it with the next upload", using the package issue > tracker would also be a way to keep track of these minor issues. For this, we have the BTS. If the issue is RC, it will prevent shit from migrating. Salsa's issue tracker doesn't have this feature. Also, I would really have preferred if Salsa's issue tracker feature was simply removed/desactivated, because every other day, there's someone proposing to replace debbug with it. Thanks but no thanks. One place is enough to look into. If you wish to write somewhere, the ITP bug is the correct place to go. On 03/02/2018 01:15 PM, Lars Wirzenius wrote: > Counter proposal: let's work on ways in which uploaders can make it > easy and quick for ftp masters to review packages in NEW. I've sent so many packages through NEW that I sometimes feel guilty about it. Though I don't know how to make it easy for them. On 03/02/2018 01:15 PM, Lars Wirzenius wrote: > The idea > should be, in my opinion, that any package that requires more than a > day of work to review should be rejected by default. Let's reject the Linux kernel, Qemu, etc.: they are too big... :) More seriously: big software are more complex, but probably also more useful for our users. So your proposal doesn't feel right. Cheers, Thomas Goirand (zigo) P.S: Why on earth do we need to have the ftpmaster@d.o as Cc? Don't you guys believe they read debian-devel without cc-ing them?
Re: A proposal for improving transparency of the FTP NEW process
On Sun, 04 Mar 2018, Thomas Goirand wrote: > On 03/02/2018 01:00 PM, Gert Wollny wrote: > > Since ftp-master also sometimes sends messages like "I let it pass for > > now, but please fix it with the next upload", using the package issue > > tracker would also be a way to keep track of these minor issues. > > For this, we have the BTS. If the issue is RC, it will prevent shit from > migrating. Salsa's issue tracker doesn't have this feature. > > Also, I would really have preferred if Salsa's issue tracker feature was > simply removed/desactivated, because every other day, there's someone > proposing to replace debbug with it. Thanks but no thanks. One place is > enough to look into. If you wish to write somewhere, the ITP bug is the > correct place to go. Every project/group can disable it at will. But it makes sense for some things (like the salsa support tracker). So the answer is no for global disabling it. Alex
Salsa issue tracker disabled for Debian group (was: A proposal for improving transparency of the FTP NEW process)
Thomas Goirand writes: > Also, I would really have preferred if Salsa's issue tracker feature > was simply removed/desactivated, because every other day, there's > someone proposing to replace debbug with it. Thanks but no thanks. As best I can tell, any project created in the Debian group https://salsa.debian.org/debian/> already has the Issues permission off, without anything else needing to be done. That seems entirely appropriate, for a Debian packaging project, for the reason you state (any Debian package should have bugs reported to the Debian BTS). Does that meet the preference you expressed above? -- \ “I distrust those people who know so well what God wants them | `\to do to their fellows, because it always coincides with their | _o__) own desires.” —Susan Brownell Anthony, 1896 | Ben Finney
Re: A proposal for improving transparency of the FTP NEW process
On Sun, Mar 4, 2018 at 5:53 PM, Philip Hands wrote: > Perhaps it's more work than licensecheck, or doesn't suit your > requirements, but there is also license-reconcile. As well as a bunch of other tools, some of which need packaging: https://wiki.debian.org/CopyrightReviewTools -- bye, pabs https://wiki.debian.org/PaulWise
Re: A proposal for improving transparency of the FTP NEW process
On Sun, Mar 04, 2018 at 11:16:29PM +0100, Thomas Goirand wrote: > P.S: Why on earth do we need to have the ftpmaster@d.o as Cc? Don't you > guys believe they read debian-devel without cc-ing them? Well, at least some active DDs *don't* read d-d@ and I can understand why. -- WBR, wRAR signature.asc Description: PGP signature
Re: salsa SSH fingerprint
On Thu, Mar 01, 2018 at 09:10:44PM +0100, Alexander Wirt wrote: > On Wed, 28 Feb 2018, Alberto Luaces wrote: > > > Hello, > > > > I am unable to find a place where the SSH fingerprint of salsa is shown. > > I want to compare it with the one displayed when I try to push some > > changes. > Just for the record weasel (thanks weasel!) implemented sshfp records [1] for > salsa. If you use a > validating resolver tell your ssh to use them to get validation > (VerifyHostKeyDNS). > > Alex > > [1] host -t SSHFP salsa.debian.org > salsa.debian.org has SSHFP record 4 1 676B02929DC7908278BCEE876EA0F1640B8264E0 > salsa.debian.org has SSHFP record 1 2 > F3C03414B13A6DF37A3296B81774EC3E28D92E7C003667CA8E17D884 33820A70 > salsa.debian.org has SSHFP record 4 2 > 3800F7A464B070E0C8B61C45FB3211BCF4D9F1408901823BE44E365C 37C6AFCE > salsa.debian.org has SSHFP record 1 1 EAA6C147FACF35BC49946D9E8B90E2235C7DA361 That is very nice! -- Guido
