Re: Documenting packaging workflows (was: finally end single-person maintainership)
Salvo Tomaselli writes: > I'm also annoyed at the default ci configuration for salsa, because importing > a > project makes a CI start to run, then fail. Then I have to one by one point > the CI file to something else, but the project will forever be "CI failing" > and > will be reported forever as such in my status page. If you go to the individual pipeline that you never wanted to run (e.g. click on the red 'X' in the overview, or the pipelines view), then you'll see a 'Delete' button in the top-right corner. If you delete all the pipelines in a repo, it reverts to thinking CI is not setup, and you'll no longer be told that the repo is 'CI failing'. BTW I just confirmed that by setting up a new repo for the purpose, and was surprised to find that I also needed to configure CI in order to get it to fail, so I think you may be right that it was once doing the annoying thing you describe, but it didn't do it to me just now. HTH Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Re: finally end single-person maintainership
Bernd Zeimetz writes: > On Mon, 2024-05-20 at 20:47 +, Scott Kitterman wrote: >> > >> > All these things should make it much more easy for other people or >> > automated tools to send merge requests or keep maintaining a >> > package in >> > case the original maintainer becomes MIA. >> >> >> Mandating a specific git layout is a big jump from not requiring a >> VCS at all. > > yes, its a big jump, but we are in 2024 and a modern workflow should be > expected from a modern distribution. Attempts at top-down imposition of new methods on Debian strike me as being unlikely to induce joy in anyone involved. After all, We're a self-selecting group of people who are prone to repeatedly walking the road less travelled. Do we even have a consensus on which layout is "best"? DEP-14 exists, but that is still candidate status, and even if it were accepted, it has a section "When to not follow the above recommendations" I suspect that there's a decent chunk of developers who generally just follow the status quo of every package they work on, without fuss. I rather like dgit for reducing the extent I have to think about this sort of thing, but I note that at least one person in this thread seems vexed by it, so we cannot even agree on the merits of that, apparently. Could it be that we mostly hear from the people at the extremities of opinion on issues like this? If so, I don't see how we're going to establish a consensus, and without that it's not going to be easy (or worthwhile) to pick a layout, nor to try and impose that on others. For anyone with an opinion, I'd suggest that you should try to make sure that DEP-14 reflects your opinion, and then work on getting people to adopt the use of DEP-14 and/or get DEP-14 accepted. That way, you'll be able to work towards consistency without having a massive and pointless fight, that will be sure to harden some people's opinion against you, making your wished-for outcome that much less likely. Cheers, Phil. P.S. I don't really give a damn about this issue, and am happy to use DEP-14 in general, or follow the current state of a particular package. If DEP-14 were to change radically, I'd be willing to switch to new recommendations, so if you care, please make it better if you can. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Re: Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
Luca Boccassi writes: > On Mon, 6 May 2024 at 11:33, Barak A. Pearlmutter wrote: >> >> > We have two separate issues here: >> >> > a/ /tmp-on-tmpfs >> > b/ time based clean-up of /tmp and /var/tmp >> >> > I think it makes sense to discuss/handle those separately. >> >> Agreed. >> >> I also don't see any issue with a/, at worst people will be annoyed >> with it for some reason and can then change it back. >> >> > Regarding b/: ... >> >> > The tmpfiles rule tmp.conf as shipped by systemd upstream ... >> > Files that are older then 10 days or 30 days are automatically cleaned up. >> >> This seems like a rather dangerous thing to spring on people. >> >> First of all, time can be pretty fluid on user machines. > > Then upon reading the release notes, on such a machine, one can simply do: > > touch /etc/tmpfiles.d/tmp.conf > > And they get no automated cleanups. This stuff is designed to be > trivially overridable, both by end-users and image builders. What I am > looking for is, what packages need bugs/MRs filed to deal with this > change, if any. Isn't this change (as presented) effectively about masking bugs? We've had people suggesting that implementing this will surprise them and disrupt their existing use of /var/tmp as scratch storage, and I've got a lot of sympathy with that, so I'm guessing that the people that are expected to benefit from this are not those that remember systems where the main distinction between /tmp and /var/tmp was that /tmp got emptied at boot time, whereas /var/tmp did not. That makes me assume that those that would be most likely benefit from such a change will mainly be users that are never going to type "/tmp" (with or without a preceding "/var"), and are therefore not going to have any idea what is being deleting for them, but will be happy never to get their disk filled. This makes me wonder what it is that we're expecting to need to delete. Is this a symptom of sloppy applications that fail to clear up the debris they create in /var/tmp? If so, is that not a bug in that application? I'd suggest that rather than clearing up after the sloppy behaviour of buggy applications, we instead leave it visible, in the hope that it can then be fixed. Of course, that's obviously not worked in some (many?) cases, so where we know of problematic packages, could we not add per-package tmpfiles.d files that name the specific paths that those packages are known to litter the system with, with appropriate deletion timeouts chosen by the Maintainer? That ought to achieve the benefit you're looking for, without hiding symptoms of future problems with other packages, and without inconveniencing anyone that's using /var/tmp as scratch space. Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Re: Binary conflict between Midnight Commander and MinIO Client
Mathias Gibbens writes: > On Sun, 2024-04-21 at 18:47 +0200, Simon Josefsson wrote: ... >> /usr/libexec/minio-client/bin/mc -> /usr/bin/mcli Might I suggest that the link goes the other way, so that the symlink lives in /usr/bin? That way the existence of the lib directory is somewhat self-documenting. If you're looking for examples, it seems that fd-find and binutils-avr do something like this (although they seem to be linking into ../lib/ presumably for historical reasons). Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Re: Epoch for node-markdown-it
Tobias Frost writes: > On Fri, Aug 19, 2022 at 10:00:58PM +0530, Nilesh Patra wrote: >> On Fri, Aug 19, 2022 at 09:51:14PM +0530, Nilesh Patra wrote: >> > > As Jonas said, an epoch cannot be undone, +really can, regardless when >> > > this is going to happen. >> > >> > I think ignoring when it happens is not the right way to see it. Even if >> > we assume that >> > upstream is going to work on this with the same effort, we will still end >> > up waiting >> > for a _decade_ for the +really to go away. >> > >> > Is tagging this along for so many years really is more worthy than an >> > epoch? >> > Note that the package might even go stale in such a long time, thought. >> >> BTW, Jonas also said, "is it unlikely that they will reach 22 >> in the foreseeable future?" > > Did you consider asking them to advance to 22+ with their next release? > Afterall, I read it that way that it that there was some issue with that 22 > version, and they might have also interest in putting that into the past? This seems like the most sensible option, given that versions going backwards cannot be great in the node eco-system either. They could possibly use it as an oportunity to switch to date-based versioning to make a clean break from the current confusion, and hopefully this sort of thing in future. Joey's scheme makes a lot of sense: http://joeyh.name/blog/entry/version_numbers/ so if they like that then I guess they'd need to release 22.20220901 (or some such). If they are against bumping the version for whatever reason, it strikes me that this situation is exactly what epochs are for, so we should probably use them for that. Littering the repo with ~really... hacks seems to me to be trading the very minor discomfort that seeing an epoch inflicts on the very few of us that ever see them, against dumping confusion on our users when they have to try to guess which versions of things they're /really/ running. Given that the only time most people get interested in versions is when they've been presented with news of a (probably urgent) bug, we should be trying to make that moment as unconfusing as possible. 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: Automatic trimming of changelogs in binary packages
Michael Biebl writes: > Am 19.08.22 um 10:35 schrieb Philip Hands: >> Paul Wise writes: >> >>> On Thu, 2022-08-18 at 21:18 +0200, Gioele Barabucci wrote: >>> >>>> Does anybody have objective objections against activating automatic >>>> changelog trimming in binary packages? >>> >>> Before we consider enabling this by default, first we need a way for >>> `apt changelog` to download the full changelog rather than loading the >>> changelog from /usr/share/doc in the currently installed package. >>> >>> Otherwise people who want to look at the full changelog for the >>> currently installed version of the package will have no easy way to do >>> so. They will have to manually find it instead, which isn't exactly an >>> easy process if you do not know where the changelogs are stored online. >> >> How about making the end of the trimmed file be a standard footer >> including a hint about how one can get hold of the rest of the >> changelog, and then have `apt changelog` look out for that footer in the >> local copies in order to know that they've been trimmed, and that it >> should therefore try to download the full version. > > If we enable trimming by default (for all packages), then apt can just > go directly to query the changelog online. > What would be the benefit for "apt changelog" to look for such a footer? I was assuming that life's a bit more messy than that, and that one might want apt to use the local copy if it's complete, and download otherwise -- if that's not the case, fine. 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: Automatic trimming of changelogs in binary packages
Ansgar writes:
> - Having to spawn an external command ("dpkg --show-changelog") just
>to access a file is more complicated.
The fact that it currently needs to dug out of the main data archive
rather than the control archive to show the user changes at install time
seemed like a decent reason to move it, but that was assuming that the
file would still end up being visible in the same place in the end.
If that were not the case then I think it would be more trouble than
it's worth.
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: Automatic trimming of changelogs in binary packages
Paul Wise writes: > On Thu, 2022-08-18 at 21:18 +0200, Gioele Barabucci wrote: > >> Does anybody have objective objections against activating automatic >> changelog trimming in binary packages? > > Before we consider enabling this by default, first we need a way for > `apt changelog` to download the full changelog rather than loading the > changelog from /usr/share/doc in the currently installed package. > > Otherwise people who want to look at the full changelog for the > currently installed version of the package will have no easy way to do > so. They will have to manually find it instead, which isn't exactly an > easy process if you do not know where the changelogs are stored online. How about making the end of the trimmed file be a standard footer including a hint about how one can get hold of the rest of the changelog, and then have `apt changelog` look out for that footer in the local copies in order to know that they've been trimmed, and that it should therefore try to download the full version. Cheers, Phil. P.S. BTW the change Guillem suggests seems like a good idea anyway: treating changelogs as control files. debootstrap being able to exclude paths during installs (#811269) is also a good idea (as mentioned in the second thread Guillem referenced.) -- I'll see if I can nudge that towards fruition. -- |)| 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: Unsolicited GNU bc patch
Thomas DiModica writes: ... > You do say it needs a better description, so I'm going to try to > give you a sense of what's going on. I was really saying that whoever feels competent to decide to accept the Merge Request for the bc package ought to come up with a better description for why they think the patch should be applied to the Debian package, but I'm sure your description will help too. Given that the patch references this thread, I'm sure it'll be found whenever needed. 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: Unsolicited GNU bc patch
Hi Thomas, Thomas DiModica writes: > Greetings, > > Yes, I keep spamming this trying to find an appropriate mailing list. I don't > remember how or why I initially stumbled across this bug report > (https://bugs.launchpad.net/ubuntu/+source/bc/+bug/1775776), but, given that > I have some familiarity with GNU bc, I decided to fix some of the issues. > Turns out, this also seems to fix the crashes reported here > (https://www.openwall.com/lists/oss-security/2018/11/28/1). I think it would > be a lot more useful to share this, as there isn't a lot to review. There are > three bug fixes and some self-defensive checks in the runtime for malformed > bytecode. Address Sanitizer tells me that these previously invalid memory > references now just leak memory. I don't appear to have broken anything in the > process, either. I'm not a member of any Debian mailing list, but I will try > to watch for responses. > > Just trying to be somewhat helpful, I took your patch, and created a merge request on our gitlab instance: https://salsa.debian.org/debian/bc/-/merge_requests/4 The patch has been slightly modified, to make it cleanly apply -- perhaps you'd be kind enough to check that I've not broken anything: https://salsa.debian.org/philh/bc/-/blob/ricinwich/debian/patches/09_crash-fixes.diff I note that bc doesn't see much activity, so I've no idea how long it might be before this makes its way into a release of the package, but at least this way it will not simply be forgotten on the mailing-list. BTW you are welcome to create an account on salsa.debian.org if you wish to contribute directly there. 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: RFC: Switch default from netkit-telnet(d) to inetutils-telnet(d)
Jeremy Stanley writes: ... > This is getting increasingly off-topic, but you're able to get a > modern SSH client to successfully connect to an old device which > only speaks SSHv1 protocol? There is: openssh-client-ssh1 https://tracker.debian.org/pkg/openssh-ssh1 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: Bug#1014908: ITP: gender-guesser -- Guess the gender from first name
Adam Borowski writes: > In other words, if you don't pick a culture, the _global_ dataset (ie, the > default one) must not assume either. It takes a lot of work to prepare > such a database, that's why this package is good to have. What exactly is it supposed to be good for? From what I can tell, at best it produces harmless nonsense, and at worst it will cause people to be misidentified in ways that will vary between mildly humourous to significantly hurtful. It seems to me about as useful as a hammer with a loose head, which would allow you to drive nails just well enough that you'll keep on using it until it breaks your toe. 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: Firmware - what are we going to do about it?
during that time I must have succeeded in doing the add-firmware dance, if only for testing, but wouldn't dream of relying on that as my real install method, or recommending it to a newbie. Frankly, it makes me wince every time I have to respond with a confusing answer to the "What do I need to install Debian?" question, so hopefully we can do better in future. -- |)| 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: Q: systemd-timer vs cron
Michael Biebl writes: > Am 15.03.22 um 03:31 schrieb Paul Wise: >> On Mon, 2022-03-14 at 11:47 +0100, Marco d'Itri wrote: >> >>> Yes, this is true. These are the unit and script that I use, and I think >>> that Debian would benefit from having something like this available in >>> some common package. >> ... >>> $(systemctl status "$FAILED_UNIT" --full --lines=100) >> >> Unfortunately for my cron jobs I need the entire output of the command >> invocation, don't want any output from prior runs of the command and >> don't want any of the output to end up in the systemd journal. >> >> So I need something like StandardOutput=mail or to add some sort of >> wrapper script to each of the relevant systemd timers. > > I might be mistaken here, but Luca hinted at > $MONITOR_INVOCATION_ID in his email which means one could easily filter > journal output for the last failed invocation using this > $MONITOR_INVOCATION_ID. > Luca, is this understanding correct? > Afaics this would cover Paul's use case Except for the "don't want any of the output to end up in the systemd journal" bit. 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: Seeking consensus for some changes in adduser
Ansgar writes: > On Tue, 2022-03-08 at 12:29 -0700, Sam Hartman wrote: >> > > > > >> Take a look at https://salsa.debian.org/vorlon/pam/-/merge_requests/3 >> >> According to the history of that patch, we have some old consensus to >> move toward usergroups and a default umask of 0002 (except for root >> which gets 0022). > > On systems that don't use usergroups for all/some users, doesn't this > change make all files writable by other users by default? That would > seem like a very unsecure change on upgrades (or as a default). AFAIK systems that don't use usergroups are already not running in standard Debian configuration, since we default to USERGROUPS_ENAB being 'yes' in login.defs (and likewise USERGROUPS 'yes' in adduser.conf). If the sysadmin has chosen to change this, then a tighter umask is appropriate, but that's what they ought to get automatically reading this from login.defs: # If USERGROUPS_ENAB is set to "yes", that will modify this UMASK default value # for private user groups, i. e. the uid is the same as gid, and username is # the same as the primary group name: for these, the user permissions will be # used as group permissions, e. g. 022 will become 002. However, I suspect that something is a bit broken about this anyway, since I just tested and get a umask of 0022 when logging in via ssh to a system with USERGROUPS_ENAB 'yes'. The downside of having this set too tight is that it makes it harder to do the thing that usergroups is supposed to facilitate: Setting up directories that have shared group ownership, with the group s-bit set, such that all members of the group can have shared access to the directory. If the umask is too restrictive, then such shared directories give the appearance of working until someone tries to edit a file created by someone else, at which point they discover that its owned by the original user, and read-only for the shared group, which stops them editing it. I'd say that working out that this is due to the umask settings is a bit beyond most users. I seem to remember trying to work out where to fix this a few years ago, and discovering that we'd managed to break bits of the way it was meant to work, such that one ends up with a 0022 umask despite what it says in login.defs. Whatever we decide, we should try to make sure that there is a single place where the local admin can change the default and have it reflected in all the places that a umask might end up being set, be that in any of our Desktop environments, on the console, via ssh, and perhaps even as defaults for things like samba. We should also ensure that the conditional behaviour that's described in login.defs really happens, so that people can change away from usergroups and automatically get a safe umask setting to match. > (Though I think the current world-readable by default is already quite > bad. It seems like a unsafe choice on both single-user and multi-user > systems...) I agree -- cases such as ~/public_html not working well with such a umask are things that the user should notice and be easily able to discover how to fix, if they so wish. 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: Is removing smell from packages OK? (Was: Why? "Marked for autoremoval on 24 March due to xdelta3: #965883")
Jonas Smedegaard writes: ... > Yes, which means you can fast-track for *THAT* reason - unrelated to > code smell, which is specifically what I was talking about. I understand that you were reacting to the idea that one can just stomp on the existing packaging simply because it "smells bad", but I don't think that was really what was being suggested. I took Andreas's question to be more about: If a package is obviously suffering badly from neglect, and urgently needs an upload anyway, is it reasonable to fix as many problems as you can while you are at it, or should one only do the bare minimum to get past the RC bug that's prompting the upload? Having looked at how it was done, I applaud Andreas for doing a proper job. If the package gets any attention from the maintainer in future, I would guess that the fact that the package is now in a much better state will be rather motivating. If the maintainer happens to disagree with any of the changes, each is in a separate commit, so would be very easily reverted, but every change seemed like a worthwhile improvement to me. 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: Is removing smell from packages OK? (Was: Why? "Marked for autoremoval on 24 March due to xdelta3: #965883")
Andreas Tille writes: > Am Thu, Feb 24, 2022 at 11:58:12PM +0900 schrieb Osamu Aoki: >> > This is probably very academic now since Andreas Tille has uploaded a >> > fixed >> > xdelta3 package today. >> >> Now that I know that the new xdelta3 is uploaded, I am OK. > > BTW, I stumbled upon xdelta3 since also a package of mine received this > autoremoval warning. Usually I try to take action on it. > > I had to decide between a "proper NMU" and an "upload that fits the > packaging standards I apply to what I upload" (which includes maintained > on Salsa, usage of dh, DEP5 copyright ... basically removing the smell > from the package). I decided for the latter but at the same time I > was aware that I violated the rules we gave given each other. FWIW I also started work on xdelta3 when I saw the removal warning for installation-guide, but when I got to the point of creating a repo on salsa you'd beaten me to it by about an hour :-) I'd gone for a slightly lighter-touch approach, in that I'd only done about half of what you'd done, but having looked, you had clearly done a much more thorough job, and I had nothing to add. I had replaced CDBS with dh simply because CDBS was FTBFS, and was only a minimal 2-includes rules file, so it wasn't really contributing anything that would justify working out how to fix it. > Given the fact that there was a nearly 4 year old patch (#895957) made > me feel that I'm not alone with this but on the other hand the creator > of the patch (thanks Jeremy for doing at least half of the necessary > work) hesitated to upload his work. This brings up again the discussion > about how much changes are allowed to simply remove smell from packages > is accepted. Given that the bug that's threatening its removal (#965883) has been ignored for almost 2 years, and is about the fact that it had a dh compat version of 5, which is completely trivial to fix, so the package certainly has the look of having been abandoned, which is why I think it's fine to do what you did, and I think you did a very good job of it. 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: Legal advice regarding the NEW queue
Scott Kitterman writes: > On Friday, February 4, 2022 6:24:56 PM EST Philip Hands wrote: >> Scott Kitterman writes: >> >> ... >> >> > Currently the only answer is join the FTP Team as a trainee when there >> > is a call for volunteers. I totally get the frustration. >> >> People could always just send additional data points to the relevant ITP >> bug, like this: >> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004021#10 >> >> If that's actually useful for FTP team members, it could be encouraged >> on the New queue page. >> >> A link to a wiki page with suggestions of what to check, and how best to >> submit reports in order to make them most useful would probably do the >> trick. >> >> Would that actually help? > > I'm not sure what the best solution is as far as notification goes. > Generally > we don't look at the ITP when reviewing packages (ITP isn't even required, so > it's really outside our scope). I only went for that because it is at least linked to from the New entry (if there's an ITP). > A comment to the ITP should get to the original packager. If it's a > worthwhile issue they can fix and re-upload. > > Most packages are currently available on Salsa even though not directly > available through the New queue. A copy of the New queue does exist on > coccia, but it's not currently readable for non-FTP Team members. It's > probably not too hard to change that if it turns out having other DDs review > things is useful. > > Right to the ITP bug and mention it on #debian-ftp might not be a bad way to > start experimenting with external reviews. OK, done that, so let's see if it's deemed useful. 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: Legal advice regarding the NEW queue
Scott Kitterman writes: ... > Currently the only answer is join the FTP Team as a trainee when there > is a call for volunteers. I totally get the frustration. People could always just send additional data points to the relevant ITP bug, like this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004021#10 If that's actually useful for FTP team members, it could be encouraged on the New queue page. A link to a wiki page with suggestions of what to check, and how best to submit reports in order to make them most useful would probably do the trick. Would that actually help? 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: Legal advice regarding the NEW queue
Scott Kitterman writes: ... > My impression is that people are tired of waiting on New, but no one > really seems to be interested in doing any work on any alternative > other than more bugs. Part of the problem is that New processing is a bit of a black box, so it's not clear to those of us outside the team how we could help. (or at least, not clear to me -- links welcome). As a random example, I noticed John Goerzen's post[1] about Yggdrasil on planet.d.o last month. John has since uploaded a package. As I write it's still in New[2], which is no great shock, as it's only been a couple of weeks. I'm quite keen to give it a spin. So, what can we do with that enthusiasm: I could grab the source and build it locally. I could squander my enthusiasm by waiting for New. I could complain about not being able to download from New, and if if the FTP team listened to me, the enthusiasm would immediately become unavailable to others, as I'd not be feeling frustrated any more. If I knew how to do it, and there were some obvious method, I could contribute to reviewing the package I want to see in the archive. On reflection, I think that removing the bottle-neck of New would be a mistake, as it would the remove the itch we all want to scratch. Instead please just provide us with the ability to scratch that itch and you may find that you suddenly have quite a few more volunteers. In the example above, eventually I will get sufficiently bored of waiting to build the package myself, which will probably be rather more effort than reviewing it would have been, so I'd much rather be able to apply that effort in a way that benefits more than just me. I fully expect the act of building my own package to precede the package passing New by about a day :-/I think this is a pretty depressing scenario, which dampens the enthusiasm of all involved on each repeat. Cheers, Phil. [1] https://changelog.complete.org/archives/10319-make-the-internet-yours-again-with-an-instant-mesh-network [2] https://ftp-master.debian.org/new/yggdrasil_0.4.2-1.html -- |)| 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: Legal advice regarding the NEW queue
John Goerzen writes: > On Tue, Feb 01 2022, Russ Allbery wrote: > >> I would hate to entirely lose the quality review that we get via NEW, but >> I wonder if we could regain many those benefits by setting up some sort of >> peer review system for new packages that is less formal and less >> bottlenecked on a single team than the current NEW processing setup. > > This is a fantastic idea. > > In fact, it wouldn't have to bottleneck packages at all. I mean, if a > quality issue is found in NEW, wouldn't the same be an RC bug preventing > a transition to testing? Looking at https://ftp-master.debian.org/REJECT-FAQ.html it looks like one could assemble many of these potential issues into a checklist that ought to be easily within the abilities of any DD to apply. If that assumption is true, we could require that one performs some number of such reviews on packages already in NEW before gaining the right to add another one of your own. Of course, we'd need some way of allocating packages to reviewers, and some way for reviewers to submit their reviews, which would need writing, but once that was done this should ensure that the effort required to do initial checks on packages was spread out more, enabling team members to concentrate on the more skilled bits of the process. It might also act as a recruiting ground for people to get more heavily involved in the FTP team. 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: Do we need to hide packages in NEW queue (Was: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not))
Andreas Tille writes: ... > May be some intermediate step would be to not hide packages in NEW queue > but exposing them as an apt source. If I'm correct this is not the case > since it had certain legal consequences for the project if code with > certain non-free licenses would be downloadable from some debian.org > address. May be NEW could be considered as some kind of pre-non-free as > long as it is not checked and the legal consequences are not valid for > us any more. But I'm not educated in international law - just asking > whether somebody might know better. I have a repository on salsa: https://salsa.debian.org/installer-team/branch2repo that allows one to easily take a collection of branches (with the same branch name) from several repos, and assemble the (u)debs that one can build from all those branches into an apt repo. The motivation for that is for testing patches to Debian-Installer, but it should work for anything, so if that (or something like it) got merged into the main salsa-CI pipeline then people could more easily decouple the testing of new packages from their progress through NEW. This does of course raise the question of whether I ought to be able to do that, since it creates apt repos, such as this (trivial) example: https://salsa.debian.org/installer-team/branch2repo/-/jobs/2365384/artifacts/browse/public/ that publish .debs from a debian.org host, that could easily be created from sources that have never been near NEW. Of course, the URL is not exactly obvious there, and the artifacts will get deleted, so maybe that's a difference, but I don't suppose it would be too hard to make that into a stable 'pages' URL and ensure that it got built often enough to keep the repo there permanently. Would that cross the line? I think the important distinction is probably that once packages get through NEW they are mirrored all over the world, by unsuspecting third parties, who live in every jurisdiction under the sun. They are also incorporated into down-stream distros, often with little/no manual oversight, some of whom then do things like selling their resulting distribution for profit. That involves other people in a lot of risks that might not apply to Debian itself, so I'd suggest requires rather more caution than trying to see what we alone can expect to get away with. Do we need to shut down salsa's ability to do the above (given that one can do all of that from a guest account, using any old code you uploaded), or is that OK because the URLs are unstable and/or obscure? (obviously, given that I did it, I think it's OK) If obscure URLs are enough, I'd think it would be OK to have things in the NEW queue available from repo URLs that were not something that one could easily mirror, and would not be an "all of current NEW repo" but rather something like an apt repo per upload, so that one could easily test stuff stuck in NEW, but wouldn't be tempted to just install everything that hits NEW by default. 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: Next attempt to add Blends to Debian installer
Andreas Tille writes: ... > As far as I understood Phil's last posting he is working on an enhanced > tasksel. Actually, what I've been working on is infrastructure to allow others to contribute to such an effort. I've recently enabled a CI pipeline in the tasksel master branch, so anyone forking that will now get the benefit of this work for free (as long as they set the CI file to be 'debian/salsa-ci.yml'). I intend to blog about the details shortly, but a quick run down is that this pipeline was triggered by a commit to my fork: https://salsa.debian.org/philh/tasksel/-/pipelines/337031 which (via a multi-project pipeline) generates a mini-iso: https://salsa.debian.org/installer-team/debian-installer/-/jobs/2364015/artifacts/file/public/gtk-mini.iso that is configured to use an additional apt repo, which in this case includes a version of tasksel built from the above branch: https://salsa.debian.org/installer-team/branch2repo/-/jobs/2364013/artifacts/browse/public/pool/main/t/tasksel/ which one can then download the min-iso for testing, and/or cause to be automatically tested with openQA, as seen here: https://openqa.debian.net/tests/overview?groupid=13=-salsa-337031:philh:tasksel:salsa-CI_tasksel where if one drills down to the logs, and search for 'salsaci', one can see that the tasksel packages came from the extra repo: https://openqa.debian.net/tests/37964/logfile?filename=_collect_data-debs.txt The same is true for udebs that are included at build time, and that would be expected to be downloaded at d-i runtime, so simply by creating named branches with the same name across all the (u)debs that one wants to test together you can get hold of a mini-iso that will use those versions in preference to the released versions, without needing to know anything about building d-i or debian CDs. Hopefully that lowers the bar enough so that people can concentrate on the bits they want to improve without immediately getting stuck on how they could possibly test their efforts. However, I've not really put much thought into what actually needs to be changed in order to address the Blends Selection problem. In the past when this has come up I've come up with some temporary hacks that worked around the lack of a decent user interface, but if we want to fix this properly then I think Steve has a point that one way to do that is to extend debconf, and then use new features in tasksel. I don't have anything like a design for how that should look in my head though -- I guess interested parties should get together and come up with a design _before_ we start trying to implement it :-) 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: Next attempt to add Blends to Debian installer
Andreas Tille writes: > Hi Steve, > > a new release cycle has started. Do you think it is possible to > implement this long wanted feature for the next release? BTW I've got almost all of the bits in place to allow one to test this just by pushing repos on salsa. The only missing bit AFAIK is getting the step where tasksel gets installed into the target system, and then run, to be able to grab the version of tasksel to use from an alternative apt repository (which is already being created as part of the salsa-CI pipeline I've got setup), which I think ought to be a case of running apt update an extra time at the right moment. Fixing that last bit is next on my TODO list. Once done, that should allow us to try things out rather more easily, and thus have a chance to demonstrate that they are ready for a wider audience. I'll follow up here once I've got all the bits in place. I also expect to have time to work on getting Blends into d-i after that. 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: merged-/usr transition: debconf or not?
Ansgar writes: >> * doing this will, in a non-negligible number of cases, trigger the >> bug to manifest on systems where that package is upgraded from a >> version where the move had not taken place to one where it has. > > Why do you claim that? > > Given packages already did such moves in the last years and you claim > this happens in a non-negligible number of cases, could you please > point to some examples where this already happens in practice? My understanding is that in order to trigger this bug you need at least to both move a file from one place to the other, and also to rename the package that contains that file or move ownership to another package. I suspect that you might also need to be unlucky with the order that apt/dpkg decides to do the installation and, depending upon how far apart the move and the rename happens, also unlucky with your choice of from and to versions of the packages in question. Given that these bugs are going to be utter bastards to reproduce, and you can be sure that we'll have enough diversity in installed systems that some people are going to manage to be sufficiently unlucky, it would be nice to know the sort of damage we might expect. It strikes me that we ought to be able to screen our own repos for packages that could be able to tickle this bug. That would give us the chance to look at what sorts of files we might realistically expect to be clobbered, it should give some indication of how many packages we should expect to be able to trigger this, and knowing this might suggest plausible work-arounds. Of course, that doesn't help with packages from third-party repos, including our downstreams, but at present we seem to be discussing this with very little hard data. It occurs to me that one could lose quite a few files on the average Debian install (if they were selected at random) without even noticing, whereas a very few files would render systems unbootable, so knowing a bit more about which files are realistically at risk would be very helpful in understanding the severity of the problem. If anyone's got good ideas about how to gather this information, I'm very happy to help with the effort to do so. 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: Consequences of the NEW queue's length [Was: Remove packages from NEW queue?]
Stephan Lachnit writes: > On Thu, Nov 18, 2021 at 4:16 PM Simon Richter wrote: >> >> On 11/18/21 4:08 PM, Stephan Lachnit wrote: >> >> > I guess this raises the (maybe already answered) question if the >> > additional license QA from NEW is for the end-product (i.e. Debian >> > stable) or for the servers that run the Debian infrastructure, which >> > of course includes experimental. >> >> The latter. > > On Thu, Nov 18, 2021 at 4:29 PM Andrey Rahmatullin wrote: >> >> On Thu, Nov 18, 2021 at 04:08:23PM +0100, Stephan Lachnit wrote: >> >> > I think this is exactly why it makes sense. I think we can trust the >> > DDs to not make any large mistakes (e.g. putting steam in main). >> The existence of NEW means we currently don't, for completely new >> packages. > > I guess these two answers sum it up then. Thanks. There is also the issue of cryptographic software, and the laws regarding its export from the USA, which Debian deals with by treating every package as though it _might_ at some point incorporate some crypto, and therefore registering every package with BXA as part of the NEW process. https://wiki.debian.org/USExportControl#Cryptographic_software_in_Debian_main_archive This may seem like a lot of silly nonsense, but apparently Debian's process is considered the gold standard by which they judge others, and I'd assume that one important factor there is that there is no back-door route by which we publish things from our mirrors prior to them going through this registration dance. Cheers, Phil. P.S. depending upon what exactly you're trying to do with pre-NEW packages, this may be part of the solution: https://salsa.debian.org/salsa-ci-team/pipeline/#using-automatically-built-apt-repository -- |)| 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: merged /usr vs. symlink farms
Luca Boccassi writes: > On Thu, 2021-08-26 at 12:16 +0200, Simon Richter wrote: >> Hi, >> >> On 8/26/21 8:38 AM, Marco d'Itri wrote: >> >> > > By my definition, these have never been working correctly, but >> > > semantics I guess. >> >> > It is not semantics. You keep saying that countless Debian and Ubuntu >> > systems are not working correctly, but since this obviously does not >> > reflect the experience of the owners of these systems then just about >> > everybody will believe that you are wrong about merged-/usr. >> >> Ideally the question whether a system works correctly would be a >> technical, not a political one that is based on a majority vote of >> people who do not look behind the facade. >> >> Simon > > Precisely - and the correct technical question is, how many bug reports > were opened by users? While I'm sympathetic with the argument that a lack of bug reports suggests that the theoretical problems (that I hope we all agree, do exist) seem not to be exhibiting themselves in the wild, it is very far from proof. If some random file disappears on your system one day, what happens? Most likely, nothing, and you never notice. Possibly, your system starts to misbehave. What do you do then? If you're a naive user, such as a recent arrival from Windows, then misbehaviour is something that you've been trained to expect and you install from scratch. The idea of reporting a bug never enters your head. If you're aware that this sort of thing really should not happen, then what happens next is probably down to how busy you are. If you're busy, you probably check your SMART stats, and having convinced yourself that the disks are OK, either restore from backup and check for what ealse is missing, or use debsums to see the extent of the damage and reinstall a package or two. Again, since you're only trying to get back to work, and didn't track down the cause, no bug report. The only bug reports you're going to get about this are either going to be the useless "Something didn't work" bugs, that I doubt would ever get tied to this cause, or the ones submitted by experienced, diligent, and time-rich bug reporters (which is a rather rare combination). The fact that we don't see bug reports should surprise no one. 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: Debian 11 Bullseye Setup Problems Error Report
Paul Wise writes: > On Wed, Aug 18, 2021 at 10:42 AM admin4 wrote: > >> is there a Debian "testing" team? > > That is composed of everyone who uses Debian and especially those who > decide to report an issue they found. While that probably accounts for the bulk of the effort, there are also people that work on this within Debian (as mentioned debian-cd does testing), and we also have several mechanical testing efforts of various sorts-- e.g.: https://jenkins.debian.net https://reproducible-builds.org/ https://openqa.debian.net/ https://ci.debian.net/ https://salsa.debian.org/salsa-ci-team/pipeline/ (there are bound to be more that I've forgotten) 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: Q: Use https for {deb,security}.debian.org by default
Wouter Verhelst writes: > On Fri, Aug 20, 2021 at 07:20:22PM +, Jeremy Stanley wrote: >> Yes transparent proxies or overridden DNS lookups could be used to >> direct deb.debian.org and security.debian.org to your alternative >> location, > > I've been thinking for a while that we should bake a feature in apt > whereby a network administrator can indicate somehow that there is a > local apt mirror and that apt should use that one in preference to > deb.debian.org. > > This could be useful for both the "I've got a slow uplink and would like > it to not be overwhelmed at the BSP I'm hosting for my Debian friends" > type as well as the "I'm an ISP and I want to provide a mirror to Debian > users so we can reduce our uplink connection a bit" type of situations. > > However, I've not been able to come up with a scheme which is simple > enough to be doable on a LAN while at the same time be usable by larger > network providers, *and* which can't also be abused by MitM attackers. We could declare that if one can find a TXT record in the local domain (e.g. _DEBIAN_LOCAL_ARCHIVE.example.com) then one should use its contents in order to configure an additional source for packages, such that one gets the signed Release file from one's normally configured sources, and then when getting subsequent files gives the local source a try, falling back to the normal setup when downloads or checksums fail. I can see that one could try a DoS of sorts by setting up the TXT record to point at a tarpit, say, but that could be handled by setting short timeouts, and giving up on the local server after some number of failures. 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
Re: merged /usr vs. symlink farms
Luca Boccassi writes: > On Thu, 2021-08-19 at 19:55 -0400, Theodore Ts'o wrote: >> On Thu, Aug 19, 2021 at 10:39:45PM +0200, Simon Richter wrote: >> > >> > I think no one likes that idea, but it's the only solution that doesn't >> > immediately fail because it requires a dpkg update that hasn't shipped with >> > the current stable release, breaks local packages (kernel modules, >> > firmware, >> > site-wide systemd configuration), or both. >> >> This could be solved if we could somehow require dpkg to be updated >> before any other packages during the the next update, no? >> >> Breaking this constraint means that we can't make "apt-get >> dist-update" work seemlessly --- but what if we were to change the >> documented procedure for doing a major update? >> >> That's not ideal, granted, but how does that compare against the other >> alternatives? >> >> - Ted >> >> P.S. I had a vague memory that there was some update in the long >> distant past where we did require a manual upgrade of dpkg first. Or >> is my memory playing tricks on me? I do know that a manual update of >> dpkg is the first step in a crossgrade > > An update to dpkg is not _required_. It might be very strongly > _desired_ which is a perfectly legitimate stance to take, but it is not > technically required, otherwise we couldn't have been shipping with > merged-usr as default in new installations of Buster and Bullseye for > 2+ years, we could not have been installing usrmerge in older > installations for 2+ years, and Ubuntu would not exist anymore since > legacy split-usr is discontinued and even older installations are being > forcibly converted. So continuing to live with this minor ~20 years old > dpkg bug as we've been doing for years is a valid option - one that > some might very, very strongly dislike and argue against which is again > perfectly legitimate, but it is de-facto an option nonetheless, because > it's the actual status quo for 2+ years. Well, quite -- we seem to have had predictions of the sky falling as a result of usrmerge and/or merged-/usr, but if it is falling it's doing it remarkably slowly. I've been paying attention to this for a while, what with being on the TC up until just before the unanimous decision (which I fully support). I'm as sure as one can be about the future that if in 20 years I am still around to type this into a supported Debian system: [ $(stat -Lc %i /bin) != $(stat -Lc %i /usr/bin) ] && cowsay Surprise! I will not see a talking cow[1]. I'm also pretty sure that the 2041 version of dpkg will either be completely relaxed about having /bin be a symlink, or we'll be using something else by then. That being the case, we might as well get on with it rather than trying to pretend that filling everyone's disks with shedloads of symlinks for a while in-between now and then is a useful thing to do. Cheers, Phil. [1] unless of course there's a reason to use some sort of bind-mount or other filesystem trickery that's invented in the interim to achieve the same result. -- |)| 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
endless discussion considered harmful
Thorsten Glaser writes: ... > I *really* don’t get why… > > ⓐ these things aren’t done in a derivative that’s *really* close > to Debian proper but can do all the funky new stuff, preserving > support for the old stuff in Debian itself, and… This issue has been explored very thoroughly, so if you've not noticed that happening then I suspect that you decided to mostly ignore it. The TC ended up deciding this because it's perfectly possible for reasonable people to agree on the facts, but weigh the importance of the various implications of those facts and available options differently. > Frankly, usrmerge is WORSE then what we had before, in all possible > ways. By saying that, in that way, you give the impression that you assume that the honestly held opinions of a lot of your fellow developers are wrong and/or stupid. Even if you think that, saying it as part of your argument tends to force people make a snap decision on which side of the argument more fools are standing, and then to pick sides, which entrenches opinion, and so is pretty counter-productive if your intention is to persuade. Making these 'unagreeable' decisions is the reason we need a TC. Sadly there are always going to be winners and losers in these cases, otherwise they wouldn't make it to the TC. Deciding to do nothing is a decision too. Do you think the TC didn't take that job seriously enough? Do you think the TC considered insufficient evidence? Did you not submit your most persuasive evidence for some reason? I would hope that you are at least willing to admit that opinions on this subject can differ even when the facts are generally agreed. Also, that while you might be upset that your opinion didn't align with the decision made by the TC, that the people making that decision were devoting their best efforts to doing what they hope will serve the project well in the long run. 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: audacity has become spyware
Luke Kenneth Casson Leighton writes: > https://yro.slashdot.org/story/21/07/05/2155212/open-source-audio-editor-audacity-has-become-spyware There's a bug to track that issue: https://bugs.debian.org/990737 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: Hosting the original youtube-dl sources on salsa?
Rogério Brito writes: > Dear people, > > As many of you may know, the RIAA issued a resquest for GitHub to take down > the youtube-dl repository. IANAL so I may be confused, but AIUI that takedown is based on the notion that there is no legitimate use for youtube-dl, which is nonsense, as this comment clealy demonstrates: https://twitter.com/mindspillage/status/1319744290340286464 "youtube-dl is pretty much the only thing that makes use of CC licenses on YouTube meaningful at all, btw." That being the case, I'd think that: a) you should ensure that the repository on salsa is fully up to date with all available branches, as a service to the public, and people should be encouraged to clone that elsewhere for extra resilience. b) if the RIAA feels the need to repeat their claims, that we should then insist that they persuade a judge that their case has some merit before doing anything about it. We could presumably consult a lawyer, but the RIAA would need to be even more moronic than I think they are to have a go at us, given that nobody in the wider world has ever heard of us, and we're going to have no trouble raising funds to defend a case, and we're very clearly not making a cent out of publishing this stuff, so they're going to have fun trying to calculate the damages. Also, see the recent Gnome case[1] for how well these things can go when people who don't know the first thing about Free Software start trying to throw lawyers at the situation. Overall even if the law managed to be sufficiently deranged to result in us losing a case against the RIAA, the light that would shed on the situation seems likely to do more harm to them, and more good to us than not getting involved in the first place. The alternative world where we stop doing good things because of people like the RIAA seems much worse. Cheers, Phil. [1] https://blog.hansenpartnership.com/lessons-from-the-gnome-patent-troll-incident/ -- |)| 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: Infrastructure for Debian Academy
jathan writes: > Hi Jonathan and Debian System Administration Team, > > We have started to organise activities around the Debian Academy > initiative and I would like to ask you if it is possible to have some > scalable hardware instance of Debian to could start trying some software > options and to do tests please to install an E-Learning platform with > people who is showing interest to participate in this project. I hope > you can help us, If you're wanting to experiment with some platforms without first having to go to the effort of setting up the servers, then I'm sure that the folks at teckids.org would be happy for you to use their instances. There are details of some of the things they offer here: https://schul-frei.org/en/2020-03-15_corona.html I've Cc:ed Dominik, who can tell you much more about teckids. It seems like a mistake not to take advantage of all their hard work, so I'd suggest that you try things out using their instances of these services before you decide that you need to install things yourself. Having done that, if you then want to install your own instance(s) it would still be wise to talk to teckids, becuase AFAIK they have this all setup via ansible, so can tell about that, and any pitfalls you might want to avoid. Don't waste the initial burst of enthusiasm in this project on installing software you don't need to install right now. Use it for generating content, or some other thing that's not already being done. 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: FTP Team -- call for volunteers
Alexis Murzeau writes: ... > If it's just about legal risk, couldn't the responsibility of the > right to redistribute of the uploaded software be moved on the > uploader instead ? How well does that work if someone outside the USA uploads software to this USA based server which is legal in their own jurisdiction, but falls foul of US law either by being on the server, or perhaps by being distributed or (re)exported, say. ISTR that uploading the ssh binaries from the UK seemed likely to involve me crossing one or other of those lines back in the days of the non-US archive (what with the RSA patent, and the export restrictions on crypto at the time). I know times have changed, but are we not still notionally informing someone of every package that goes through NEW? Telling them (perhaps in a queued email that doesn't get sent any more) that each and every package in Debian may well include crypto at some future date, if it doesn't already, and declaring an initial point of distribution. I would suspect that we might want to check that technical changes to this process remain compatible with the paperwork, because the paperwork may well be harder to change than the technology, and keeping the paperwork in good working order may be a useful shield if some capricious maniac ever managed to be in charge of things. 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
packages declaring a relation to mailx (virtual package)
Hi, While installing a new system, I was bitten by #253513 which lead me to wonder how I had ended up with mailutils rather than bsd-mailx. It seems that this was the result of installing emacs, which pulled in exim4 and thus exim4-base, which recommends the virtual package 'mailx' which is provided by mailutils. Declarations of a relationship to mailx (sorted by frequency)[1]: 22 bsd-mailx | mailx 9 mailx 3 heirloom-mailx | mailx 2 mailx | mailutils 2 mailutils | mailx 2 bsd-mailx | mailx | mailutils 1 s-nail | mailx 1 mutt | mailx | mail-transport-agent 1 heirloom-mailx | bsd-mailx | mailx 1 heirloom-mailx | biabam | mutt 1 exim4 | mail-transport-agent | mailutils | bsd-mailx | mailx 1 bsd-mailx | mailutils | s-nail | mailx It seems that most (26) packages are explicitly preferring bsd-mailx, which seems fair enough to me. heirloom-mailx is a dummy package that depends on s-nail, where s-nail does not actually provide mailx, so I suspect that mentions of both of those could be bugs. The most popular remaining option is to list mailx before any real package, which is presumably what leads to the unexpected behaviour. As far as I can see, mailutils is only explicitly preferred to bsd-mailx in three cases: fwanalog & wims Depends: mailutils | mailx debarchiver Recommends: exim4 | mail-transport-agent | mailutils | bsd-mailx | mailx Given that, it seems to me that we should somehow ensure that when one needs 'mailx' one can be sure to get bsd-mailx (unless one explicitly chooses otherwise). However, hard-wiring this preference into so many packages doesn't seem very elegant to me, and would be a pain to change if we ever wanted to switch defaults. Is there perhaps some trick in apt that could fix this so that the packages only need to depend on mailx? Alternatively, might a 'default-mailx' virtual package that only bsd-mailx provides be the answer, such that all of these then could declare the dependency as: default-mailx | mailx Can anyone suggest a better way of making bsd-mailx the distribution-wide preference for satisfying dependencies on mailx? Cheers, Phil. [1] FYI the above figures were arrived at by using these commands: for i in $(apt-cache showpkg mailx | sed -ne 's/ \([^ ,]*\)\b.*/\1/p' | sort -u) ; do apt-cache show $i | sed -ne 's/^\(D\|R\|S\)\(epend\|ecommend\|uggest*\)s: \(\|.*, *\)\([^,]*mailx[^,]*\)\(.*\)$/\4:'"$i"'[\1]/p' ; done | sort -V -u > /tmp/mailx-deps.txt cut -d: -f1 /tmp/mailx-deps.txt | uniq -c | sort -nr The longer list is here: signature.asc Description: PGP signature bsd-mailx | mailutils | s-nail | mailx:rkhunter[R] bsd-mailx | mailx | mailutils:backupninja[D] bsd-mailx | mailx | mailutils:psad[D] bsd-mailx | mailx:aide-common[D] bsd-mailx | mailx:amanda-common[D] bsd-mailx | mailx:amanda-server[D] bsd-mailx | mailx:apticron-systemd[D] bsd-mailx | mailx:apticron[D] bsd-mailx | mailx:automysqlbackup[D] bsd-mailx | mailx:bacula-director[D] bsd-mailx | mailx:bareos-director[D] bsd-mailx | mailx:devscripts[S] bsd-mailx | mailx:fcheck[D] bsd-mailx | mailx:gridengine-common[D] bsd-mailx | mailx:hylafax-server[D] bsd-mailx | mailx:icinga-common[D] bsd-mailx | mailx:inn[D] bsd-mailx | mailx:libapache2-mod-evasive[D] bsd-mailx | mailx:logrotate[R] bsd-mailx | mailx:nagios4-common[D] bsd-mailx | mailx:reboot-notifier[D] bsd-mailx | mailx:sharutils[S] bsd-mailx | mailx:ssl-cert-check[R] bsd-mailx | mailx:ui-auto[D] bsd-mailx | mailx:uucp[D] exim4 | mail-transport-agent | mailutils | bsd-mailx | mailx:debarchiver[R] heirloom-mailx | biabam | mutt:autopostgresqlbackup[R] heirloom-mailx | bsd-mailx | mailx:aptitude-robot[S] heirloom-mailx | mailx:autopostgresqlbackup[D] heirloom-mailx | mailx:drbd-utils[R] heirloom-mailx | mailx:sn[D] mailutils | mailx:fwanalog[D] mailutils | mailx:wims[D] mailx | mailutils:smartmontools[R] mailx | mailutils:smartmontools[S] mailx:bzr-email[S] mailx:cruft[S] mailx:exim4-base[R] mailx:fail2ban[S] mailx:integrit[R] mailx:mariadb-server-10.3[S] mailx:mpt-status[S] mailx:mysql-server-5.7[S] mailx:tua[D] mutt | mailx | mail-transport-agent:metche[D] s-nail | mailx:apcupsd[R] -- |)| 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
Re: Heads up: persistent journal has been enabled in systemd
Martin Steigerwald writes: > Martin Steigerwald - 06.02.20, 12:26:32 CET: >> Vincent Bernat - 06.02.20, 07:58:32 CET: >> > ❦ 6 février 2020 09:50 +11, Dmitry Smirnov : >> > >> and 2) continuing to use rsyslog isn't an option if the default >> > >> changes.> >> > > >> > > No. I just don't want default to change. IMHO rationale for this >> > > is >> > > weak but everybody keeps arguing that it would not be a big deal. >> > > In time we will see how that goes (what could possibly go wrong?) >> > > but why do the change in first place? >> > >> > To not have logs duplicated in two places. >> >> I solved this by removing Systemd from my systems. >> >> And now what? > > And before that I had Systemd only log to /run. > > Especially as I found that I did not use journalctl in my daily practice > anyway. > > So why would removing rsyslog from the default install the only viable > approach to solve duplicate logging? Well, since we're apparently meant to be obsessed about what it is like to accept every default, then let's assume for a moment that you are asking about rsyslog with the maintainer supplied rsyslog.conf. Having just installed this laptop, I can run this: # grep -r '5590629f1f60.*delivery successful' /var/log /var/log/mail.log:Feb 6 14:51:14 rummy dma[164f55.5590629f1f60]: delivery successful /var/log/mail.info:Feb 6 14:51:14 rummy dma[164f55.5590629f1f60]: delivery successful /var/log/syslog:Feb 6 14:51:14 rummy dma[164f55.5590629f1f60]: delivery successful which you'll note is actually triplicating log messages by default. HTH 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: migration from cron.daily to systemd timers
Daniel Leidert writes: > Am Mittwoch, den 08.01.2020, 08:17 +0100 schrieb Philip Hands: > > [..] >> How about modifying the shipped /etc/default/spamassassin to include a >> comment explaining what's going on, and how to enable the timer instead? > > It seems I misread this part at first. Is it your suggestion to keep the > default behavior and explain how to enable the timer instead? My suggestion was simply that by modifying the file, one provokes a question on upgrade about whether the administrator wants their modified version (presumably modified to have CRON=1 set) or the new one from the maintainer (now with a nice comment about what's new, that should be enough to give the admin all the information they need). If a system has an unmodified file (so with CRON=0, among other things) then it gets quietly upgraded to the one with a comment, which might even turn out to be useful, when someone used to the old ways of doing things goes to set CRON=1 and gets the chance to learn something new. I don't really care what that comment says, as that's up to the maintainer of the package, and how they intend to deal with this in the future, but I'm really not a fan adding unnecessary questions to debconf. 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: migration from cron.daily to systemd timers
Daniel Leidert writes: > Am Mittwoch, den 08.01.2020, 15:36 +0100 schrieb Philipp Kern: >> On 2020-01-08 14:27, Daniel Leidert wrote: >> > And what s the benefit of this change: Getting rid of cron? >> > >> > The very simple thing is: CRON=1 enables a cron job. It does *not* say: >> > "Please >> > enable something different as long as it achieves the same." There is >> > nothing >> > wrong with the cron job and it works perfectly fine. So I don't want to >> > have it >> > replaced by something less transparent. >> > >> > Why do you resist the appropriate behavior of raising a question >> > whether the >> > user wants you to replace cron by systemd? >> >> I don't think yelling in this way is helpful. > > Stop it. Right here and right now. I didn't yell at anybody. I raised some > serious questions I believe are justified by your comments. Erm, no -- I think you're conflating two Phils now (he has an extra 'p', and a different surname ;-) ) The strong reaction he's complaining about was provoked by what I said. I'm not really sure why you'd react like that, but just in case it helps, I'll try to clarify where I'm coming from: I have no particular opinion about keeping or discarding cron, but I do object to questions that almost nobody wants to answer being shoved into debconf in a way that means they may end up being duplicated across multiple packages, and will then be left behind by future developments, while not being easy enough to remove for them to ever go away. If that can instead be dealt with by adding a useful comment in a file that might well be the place that one would be looking when one needed the information in that comment, then that seems like a better way of doing the same thing. 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: migration from cron.daily to systemd timers
Daniel Leidert writes: ... > Please ask during installation and give the question an appropriate priority. > By choosing the priority you can even achieve a "silent" transition for > "normal" users and let more advanced users decide. This strikes me as clutter that will never be removed from debconf, so let's not decide to do that for every package that might need a timer. How about modifying the shipped /etc/default/spamassassin to include a comment explaining what's going on, and how to enable the timer instead? Anyone who's set CRON=1 will then get warned about the maintainer's modified version, which should catch their attention. Everyone else will get a handy hint about the new setup if they ever go to set CRON=1 in future. 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: Git Packaging Round 1: Hopefully Easy Stuff
Jonathan Carter writes: > On 2019/08/14 20:02, Sam Hartman wrote: >> If you're going to set up a repository for Debian packaging on Salsa, >> you need to either: >> >> 1) turn off merge requests > > That would be quite horrible IMHO, this is the de facto method that > young (let's say under 35 years old) developers use to submit > improvements to other projects. We have all the infrastructure and tools > conveniently in place to accommodate this, it seems suboptimal to treat > MRs as a second class citizen. Would it not be possible to have a webhook (or similar) that could receive notifications of MRs, and automatically create a bug report containing the current state of the MR as a patch? Of course, if people then fiddle with their MR, the patch may well be useless, which is likely to force one to actually deal with the MR within gitlab anyway (or to bugs in the BTS with streams of mostly useless generated patches ... but at least one would have captured the history that way). If the generated bug report included links to guide the maintainer straight to the diff as it currently exists that would minimise the pain for non-MR-happy maintainers ... along with a link to a wiki page where we could collect tips like the one just mentioned by Holger. The webhook could also add a comment to the MR linking to the new bug in the BTS. That way, people that intend to mostly ignore MRs could still allow people to make contributions in their preferred style, while gently guiding them towards interacting via the BTS, simply by adding the relevant webhook to the project's Integrations settings. That seems rather more welcoming than simply turning MRs off, which is likely to make some people go and find something more enjoyable to do with their time than contributing to that project. 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: Salsa.d.o: Please support the implementation request for a global config option to change the default for "Custom CI config path" in Gitlab
Simon McVittie writes: > For those reasons I think something in debian/ would be a better default. > The request in #26 was for debian/.gitlab-ci.yml. I personally think > a non-hidden file (debian/salsa-ci.yml or debian/gitlab-ci.yml) would > make more sense than a hidden file, but that's just bikeshedding > really. The salsa-ci.yml name has the distinct advantage that it is kind to our downstreams, as it makes it obvious where that file is supposed to work. 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: getting rid of "testing"
Michael Stone writes: > On Tue, Jun 25, 2019 at 08:07:51PM +0800, Paul Wise wrote: >>On Tue, Jun 25, 2019 at 8:04 PM Michael Stone wrote: >>> Having "stable" in sources.list is broken, because one day stuff goes >>> from working to not working, which requires manual intervention, at >>> which point someone could have just changed the name. Having codenames >>> in sources.list is broken, because even people who have been developers >>> for two decades can't remember which release is which without looking it >>> up. (Which is harder than it should be; maybe we should have had >>> /etc/debian-releasenames or somesuch from the beginning. lsb_release -a >>> is helpful when available but doesn't have context, and many users don't >>> know it exists.) >> >>Personally, I can remember the names and their order much better than >>which version goes with which codename or suite :) > > Well, every problem domain has its rainman :) For the rest of us, > there's google. Personally, I use wikipedia's page about debian revisions, and it's not that uncommon an event for me to need to look that up just to make sure I've not made a stupid typo. I like the idea of adding the list of releases somewhere (probably under /usr/share/doc though, and including dates for start and end of support etc. perhaps) 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: getting rid of "testing"
Adam Borowski writes:
> On Tue, Jun 25, 2019 at 08:08:22AM +0200, Ansgar wrote:
>> Hi,
>>
>> what do people think about getting rid of current suite names ("stable",
>> "testing", "unstable") for most purposes? We already recommend using
>> codenames instead as those don't change their meaning when a new release
>> happens.
>
> And for this exact reason so many people want "testing" not "buster".
>
> This way they get 5-days-newest versions of everything, without having to
> suffer broken uploads, broken dependencies, etc.
>
> Using "buster" would mean that at some moment their updates suddenly stop,
> and they have to manually migrate to the next version.
>
>> Related to that I would like to be able to write something like
>>
>> deb http://deb.debian.org/debian debian11 main
>> deb http://security.debian.org/debian-security debian11-security main
>>
>> in sources.list as codenames confuse people.
>
> Hell no! Even though I'm among most active DDs around, I just had to look
> up whether "debian11" means Buster or Bullseye.
>
> It's same eg. for processor names: "Skylake" means Skylake, which is used
> within 6 or 7 different numbering schemes. Even people who care what
> processor that is will so often need to look up versioning numbers -- as the
> public names are about marketing segments and so on, not about how a
> processor behaves.
>
> A code name is also so much easier to talk about, especially in speech -- a
> codename is one or two fairly unique syllables, while a number is longer,
> and it's usually surrounded by other numeric values within other semantic
> domains.
These things are clearly a matter of taste.
For me, the numbers would be _much_ more useful.
I'm perfectly capable of typing slink when I meant stretch. The coming
era of b* releases is going to be a right pain for me.
I would certainly not end up typing 2.1 when I meant 9 though, and if
somehow I did, I would be able to notice the mistake instantly, whereas
my dyslexia will cheerfully hide the wrong name for long enough to allow
quite a lot of hair pulling.
The version numbers are also showing up on login and desktop backgrounds
so I'd guess the bulk of users know exactly which number they're up to,
but a pretty vague about which codename goes with that.
Oh, and for me that also applies to speech -- if you say 10 to me,
there's no way I'll later remember 9, but if you say buster, I'm quite
likely to remember "two sylables, begins with B".
Can we not just have both?
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: Content Rating System in Debian
Philipp Kern writes: > On 2019-06-25 09:31, Philip Hands wrote: >>> Russ Allbery: >>>> It sounds like a whole ton of work to get a useful amount of coverage >>>> (not >>>> to mention bothering upstreams with questionnaires that I suspect >>>> many of >>>> them would find irritating -- I certainly would with my upstream hat >>>> on), >>>> and I'm not clear on the benefit. Do you have some reason to believe >>>> that >>>> this is a common request by users of Debian? If so, could you share >>>> with >>>> us why you believe that? >>> I'm discussing about CRS inspired from Google Play. >> Do Google Play not pay IARC for this? > > App developers are generally forced to self-rate their apps, otherwise > they disappear from the store. Right, but is that not done by filling out a questionnaire that is somehow administered/rated by IARC, which presumably means that they need to be paid for providing that somewhere along the line (or is it all government funded?). Also, IARC claim to keep ratings under review, which presumably also needs to be paid for somehow. I was guessing that they collect subscriptions from the platforms to cover the costs. 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: Re: Content Rating System in Debian
Philip Hands writes: > What is it going to cost us to get 'bison' rated PG? Why is this > useful? Erm, not 'PG' -- I meant whatever the "Anyone can watch this" label is. Although, I guess one could perhaps argue PG for bison: One could use it to build something that generates offensive content, and perhaps the joys of compiler writing should be saved for an appropriate age ;-) 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: Re: Content Rating System in Debian
Bagas Sanjaya writes: > Russ Allbery: >> It sounds like a whole ton of work to get a useful amount of coverage (not >> to mention bothering upstreams with questionnaires that I suspect many of >> them would find irritating -- I certainly would with my upstream hat on), >> and I'm not clear on the benefit. Do you have some reason to believe that >> this is a common request by users of Debian? If so, could you share with >> us why you believe that? > I'm discussing about CRS inspired from Google Play. Do Google Play not pay IARC for this? I would assume that there is a fee that covers IARC's costs in running the service, which is then paid out of the profit that Google makes on the games. What is it going to cost us to get 'bison' rated PG? Why is this useful? Also, it seems clear to me that the same game in all Linux disros is very likely to get the same rating, so this would be better done as a distribution agnostic level, preferably by someone that makes a profit from games or content anyway. For instance, I'd imagine that Steam have some sort of rating mechanism, which might even use IARC already, so one might be able to achieve this aim by talking to them about getting access to their system somehow, and perhaps getting them to include things in their database that they don't actually distribute themselves. One might imagine that one could buy a subscription to their rating database, say. Alternatively, parents who are interested might simply decide to subscribe to Steam if Steam provided a package that allowed subscribers to see the ratings for packages they were about to install. (I'm only saying Steam here because they've been quite Debian friendly AFAIK, but there's nothing stopping anyone else offering such ratings as a service to Debian users). Asking Debian to do it seems like it's just asking for trouble -- what happens when a child is traumatised by content that most people find completely innocuous in a package we've not yet got round to rating? 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: The Difference between debcheckout and dgit and what they try to accomplish
Ansgar Burchardt writes: > On Thu, 2019-06-20 at 10:52 +0200, Enrico Zini wrote: >> This reminds me of something that popped up in a dinner discussion a few >> days ago: mandate documenting workflow in debian/README.source no matter >> what, and allow to symlink that file to a repository in >> /usr/share/doc/somewhere/ as we do for common licenses. > > My workflow also includes getting changes merged upstream, so any such > documentation would need to include the upstream workflow. Information > how to contribute also includes code style (spaces vs tabs), naming > conventions and so on. > > I'm not willing to write such things down for Debian for the rare case > someone might read it; there are enough other things that need to be > done. I'm glad for you that all those details are currently retained by your brain, but I suspect that if you're fortunate enough to live long enough there will come a time when such things manage to evaporate from memory. That being the case, you might want to consider writing such documentation while it's trivially easy for you to do so from memory, so as to save the frustration of your future self forgetting them. As a side effect, you'll also be saving anyone else from the effort of finding all that out about the upstreams etc. in case your interests change, and someone else has to take over your packages. You also seem to be making the perfect the enemy of the good here. I'd imagine that a partial description of your workflow would be better than none, and if anyone ever asks about the extra bits you could answer them by adding missing details to the package and thus get closer to full documentation without significant additional effort. 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: Consensus Call: Do We Want to Require or Recommend DH; comments by 2019-06-16
Adrian Bunk writes: ... > Often the most difficult part of packaging are the unique rules the > Debian ftp team requires for debian/copyright that are not required in > distributions with actual lawyers. That's a completely separate topic. That seems needlessly snide, and glosses over the fact that we are bound by constraints that other distributions are not, such as giving a damn about the license conditions we inflict on our downstreams, which I suspect the lawyers you allude to are not being retained to contemplate. 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: usrmerge -- plan B?
Michael Stone writes: > On Mon, Nov 26, 2018 at 03:08:09PM +0100, Marco d'Itri wrote: >>I disagree both that simple testing (that you could do with a KVM >>snapshot as well) would be hard and I disagree that the benefits of >>merged-/usr would be minor. > > Nobody has thus far pointed out a single benefit to someone merging usr > on an ordinary system. I'll bite. I have systems that were installed ages ago, which now have insufficiently large root partitions. Some of them I've gone through the rather delicate procedure of resizing partitions, some of which contain LVM, to make things fit. Some of them I've been able to move / onto LVM (with the side benefit of being able to combine / and /boot into one, and thus make it big enough to have a copy of grml on there). Some are now populated with a lot of symlinks to other partitions in a painful attempt to keep them small enough to be useful. Installing usrmerge seems like a way to restore sanity to the latter case. Any of the above fixes requires one to do things that can easily result in a trashed system if you do things in the wrong order, or get the details wrong, so are not for the faint-hearted. BTW whenever anyone says something like "Nobody" or "Never" in these discussions, they are just asking to be contradicted. I'm pretty sure that people have been pointing out advantages of various sorts for some time, but that you have your filters turned up high enough that none of them have managed to lodge in your memory. (I cannot be bothered to actually come up with a citation, because it's pretty clear that doing so would make no difference). 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: usrmerge -- plan B?
Svante Signell writes: ... > Who can even thake the time to read all these verbalism. This is a criticism of an attempt to educate, made from a position of ignorance. I don't think we need we need this on our mailing lists. > Things could be written more condensed. Given that Simon was replying to a mail that was complaining about a lack of detailed justification, criticising him for providing a series of detailed justifications is deranged. If you don't like reading about the details, you should have killed the thread at the first mail. ... > Maybe he is a politcian? I guess that was supposed to be a joke, but sadly it reads like an ad hominem attack (as did your opening sentence for that matter: the one about Simon writing long emails, which I trimmed in an attempt to accommodate your tiny attention span). 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: Debian Buster release to partially drop non-systemd support
Ansgar Burchardt writes: ... > Please no. I don't think it would help Debian to have toxic people > maintain packages. You are using a fairly blunt tool if you judge people based on their preference of operating system. ;-) Let's instead judge people by the way they behave. I admit that I have encountered individuals who were in some sense supportive of Devuan and were also at least somewhat antagonistic, but it seems unlikely they will be the ones to get in touch and offer help. That being the case, I seriously doubt you need to be concerned. If people with a preference for Devuan wish to work constructively within Debian, we should welcome them. 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: Solomonic Ruling applied to namespaces (was Re: Updating the policy for conflicting binaries names ?)
Guillem Jover writes: > then suddenly there's no one to claim it, and it can be > taken by a third party. Can you name any cases where that has happened? I was under the impression that the intent was that a disputed name would be deemed unavailable to all after such a ruling. 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: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]
Philip Hands writes: > Paride Legovini writes: > >> Adam Borowski wrote on 14/09/2018: >>> On Thu, Sep 13, 2018 at 11:28:36PM +0200, Thomas Goirand wrote: >>>>> For example, in the Rust team, we have been discussing about packaging >>>>> fd (a find alternative developed using rust [1]). We are planning to >>>>> install it in /usr/bin/fd .. but this conflicts with something >>>>> completely different, fdclone a clone of fd, a MS-DOS file browser... >>>> >>>> fdclone isn't a shell utility, you just start it once, then you use its >>>> ncurse-like interface. Renaming it /usr/bin/fdclone wouldn't be a >>>> problem at all >>> >>> It _already_ is a symlink pair between "fd" and "fdsh". For the executable, >>> "fd" is the master, "fdsh" the slave, the man page prefers "fdsh". >> >> I am the prospect maintainer of fd-find; thanks for spotting this. I >> will ask the current maintainer of fdclone if he's willing to drop the >> 'fd' binary, keeping only 'fdsh' (upstream installs both as hard links). >> Shouldn't this be possible, I'll install the fd-find binary and man as: >> >> /usr/share/fd-find/bin/fd >> /usr/share/fd-find/man/man1/fd.1.gz >> >> and provide the convenience symlinks: >> >> /usr/bin/fdfind -> /usr/share/fd-find/bin/fd >> /usr/share/man/man1/fdfind.1.gz -> /usr/share/fd-find/man/man1/fd.1.gz >> >> Does this sound reasonable? > > It strikes me as rather presumptious to be trying to grab a new two > letter command at this point in the history of *nix (particularly when > it is already in use). > > Personally, I'll never willingly install a binary named that, because it > seems very likely to tickle my dyslexia. I'd expect it to make me very > grumpy if I ever have to maintain a script that includes references to > both df and fd nearby one another. Ignore the above -- I managed to misread what you asked as dropping 'fd' into /usr/bin, which is the oposite of what you were actually asking. Sorry if I introduced any aditional confusion. 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: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]
Paride Legovini writes: > Adam Borowski wrote on 14/09/2018: >> On Thu, Sep 13, 2018 at 11:28:36PM +0200, Thomas Goirand wrote: >>>> For example, in the Rust team, we have been discussing about packaging >>>> fd (a find alternative developed using rust [1]). We are planning to >>>> install it in /usr/bin/fd .. but this conflicts with something >>>> completely different, fdclone a clone of fd, a MS-DOS file browser... >>> >>> fdclone isn't a shell utility, you just start it once, then you use its >>> ncurse-like interface. Renaming it /usr/bin/fdclone wouldn't be a >>> problem at all >> >> It _already_ is a symlink pair between "fd" and "fdsh". For the executable, >> "fd" is the master, "fdsh" the slave, the man page prefers "fdsh". > > I am the prospect maintainer of fd-find; thanks for spotting this. I > will ask the current maintainer of fdclone if he's willing to drop the > 'fd' binary, keeping only 'fdsh' (upstream installs both as hard links). > Shouldn't this be possible, I'll install the fd-find binary and man as: > > /usr/share/fd-find/bin/fd > /usr/share/fd-find/man/man1/fd.1.gz > > and provide the convenience symlinks: > > /usr/bin/fdfind -> /usr/share/fd-find/bin/fd > /usr/share/man/man1/fdfind.1.gz -> /usr/share/fd-find/man/man1/fd.1.gz > > Does this sound reasonable? It strikes me as rather presumptious to be trying to grab a new two letter command at this point in the history of *nix (particularly when it is already in use). Personally, I'll never willingly install a binary named that, because it seems very likely to tickle my dyslexia. I'd expect it to make me very grumpy if I ever have to maintain a script that includes references to both df and fd nearby one another. 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: Urging for solution to the slow NEW queue process
Andrey Rahmatullin <w...@debian.org> writes: > On Wed, Apr 11, 2018 at 07:08:21AM +, Lumin wrote: >> Briefly speaking, if a DD was told that "Thank you for your contribution >> to Debian but please wait for at least 2 months so that your package >> can enter the archive.", will the DD still be motivated working on NEW >> packages??? Please convince me if you think that doesn't matter. > But most DDs already know about this? > >> Let's have a look a this chart[2]. Obviously the NEW queue became >> somewhat weirdly long since about a year ago. We can also move >> to the middle part of this page[3] where we can estimate a median >> number of time for a package to wait in the NEW queue. The median is >> **2 month**. Things has been going in the BAD direction compared >> to the past. > There are 287 packages on that page. > 154 of them have "node-" in the name. Of the packages that have been in the queue for more than 3 months, only 3 are not node packages. Looking at the oldest item in the queue (node-mimelib, 7 months), I see that the upstream README[1] was changed on Mar 11th to read: NB! This project is deprecated All users of this project are urged to find an alternative as it is not maintained anymore. Obviously, this is nothing to do with whatever caused it to become stuck in NEW, but it strikes me as symptomatic of the state of the node ecosystem, which hardly makes things easy for those packaging node packages, nor for the ftp-masters. If one excludes the node packages, the current state of NEW looks rather good. It suggests[2] that the average wait for non-node packages is about a fortnight. This is something for which I think we should be congratulating the ftp-masters. Cheers, Phil. [1] https://github.com/andris9/mimelib [2] of course, if hundreds of packages were whizzing through in under an hour, that would not be visible by glancing at the NEW queue, so the queue doesn't give a full picture. -- |)| 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: A proposal for improving transparency of the FTP NEW process
Gert Wollny <gw.foss...@gmail.com> writes: > Am Freitag, den 02.03.2018, 17:49 +0100 schrieb Philip Hands: >> Gert Wollny <gw.foss...@gmail.com> 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: A proposal for improving transparency of the FTP NEW process
Gert Wollny <gw.foss...@gmail.com> 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? 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: A proposal for improving transparency of the FTP NEW process
Gert Wollny <gw.foss...@gmail.com> writes: ... > Short version: Use the salsa per-package issue tracker for problems > that come up with the review in NEW. Is there any significant benefit that this brings over having the same interaction in the BTS? I realise that Gitlab is the new shiny thing, but there is a cost to using two issue tracking mechanisms when one would do, and for packages where the maintainer is not actually using salsa, what then? 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: Extended Long Term Support for Wheezy
On Wed, 21 Feb 2018, m...@linux.it (Marco d'Itri) wrote: > On Feb 21, Antonio Terceiro <terce...@debian.org> wrote: > >> Maybe the proposal needs to be clarified, but my understanding was that >> some companies are willing to fund a longer LTS for a restricted set of >> packages and architectures¹, but that the product of that would continue >> to be available for anyone. > Indeed. If the scope of the project is reasonable and clearly defined > then I would definitely be in favour of distributing the results in the > Debian archive. I'm in favour of making it possible for our users to build structures that enable longer support periods if that's what they require. There would seem to be a need for an OS that would have support measured in decades rather than years, and we should not get in the way of Debian being that OS. If doing this stepping-stone to longer support allows sponsors to get used to funding such very-long-term support, then I think we should give it a chance to develop as part of Debian. Once the funding dries up for Wheezy, we can always decide it didn't really work out and not do it for future releases. I would however suggest that it should not be part of the normal mirror area, since: There is going to be a step-change in the level of support, with many more packages dropping out of support. Users should have to notice this and update their sources.lists as they see fit. We don't want to inflict ever increasing demands for space on the mirror network by keeping ever older, mostly obsolete, distros around. Especially since it might be that very few people end up using them. I'd have thought that the sponsors should be willing to set up mirrors for these repos. if there is a need for mirrors (since they're quite likely to do that anyway for internal use, and so just need to provide public access to those). 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?
On Sat, 17 Feb 2018, Michael Meskes <mes...@debian.org> wrote: >> Minification is quite comparable to compilation. I will give you some >> examples from my frustration with Drupal8 in this answer. This can no >> longer be seen as source code: >> ... > > I disagree, it is not maintainable source code, yes, but source code > nonetheless. The settled opinion of the FTP team (and the TC for that matter) is: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839570#235 that for our purposes it is not source code. 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
Bug#886238: closed by Bastian Blank <wa...@debian.org> (Re: Bug#886238: Please introduce official nosystemd build profile)
On Mon, 08 Jan 2018, Hleb Valoshka <375...@gmail.com> wrote: > On 1/8/18, Don Armstrong <d...@debian.org> wrote: > >> Devuan does not support reading the new upstream configuration file, >> which is what new patches are needed to support. This is pretty classic >> bitrot of an underused/under-tested execution path. > > It does: > https://git.devuan.org/devuan-packages/dnscrypt-proxy/blob/suites/ascii-proposed/debian/dnscrypt-proxy.init Well done. I note that your init script is not the same as the one in the bug's patch, and is also not the same as the one that reverting the commit you were on about would have resurrected. I would hope that between the three versions there is one (or a combination) that would function both on a system where the systemd support files are present (as in the Debian package) and where they are absent (as is the case in yours). If not, presumably that would not take a vast effort to achieve. That being the case, I'd suggest that you mail the bug with your script attached, pointing out the interesting differences between it and the existing patch, and perhaps offering to help testing the result. I sincerely hope that doing that would result a rather happier outcome than your efforts to date seem to have achieved. 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
Bug#886238: closed by Bastian Blank <wa...@debian.org> (Re: Bug#886238: Please introduce official nosystemd build profile)
On Sun, 07 Jan 2018, Hleb Valoshka <375...@gmail.com> wrote: > On 1/5/18, Debian Bug Tracking System <ow...@bugs.debian.org> wrote: >> From: Bastian Blank <wa...@debian.org> > ... >> As you have been already told by several people, Debian supports >> systemd-less systems. If you find bugs running in this mode, please >> file bug reports. > > I've already posted a bug number which perfectly shows how bugs for > systemd-less systems are treated. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850069 > >> Control: severity -1 wishlist > > W_I_S_H_L_I_S_T_! > > System is broken, Wrong. Which bit of this reply is not clear to you? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857322#10 Did you perhaps miss the fact that the two bugs had been merged? Without the merged bug, there is no patch, so in that case you would have nothing to complain about (maintainers are _NOT_ required to fix such bugs, but should not reject patches without good reason). With the merged bug, we have a patch that is described as "prelimiary" and suggests a way of testing it. : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857322#25 Therefore it needs testing before one could legitimately complain about the maintainer blocking it. Have you contributed to that testing? If so, why is that not visible in the bug? If not, how about putting your efforts into something useful (testing), rather than wasting your and our time with this intemperate drivel? 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: Bug#877212: [Pkg-javascript-devel] Bug#877212: node-d3-color: B-D npm not available in testing
Sean Whitton <spwhit...@spwhitton.name> writes: > Hello Jérémy, > > On Tue, Oct 03 2017, Jérémy Lal wrote: > >> It might be a good idea to make policy more explicit about downloads >> during build. > > I'm not sure how it could be more explicit: > > For packages in the main archive, no required targets may attempt > network access. The problem seems to be that Praveen reads that prohibition as implying that it is totally OK to do this when not in main. This strikes me as equivalent to reading: All men are mortal, Socrates is a man, and concluding that women are immortal. The correct way to read this bit of policy is that network access during build is considered such a bad idea that it is not allowed under any circumstances in Debian proper (main). That being the case, it is a safe bet to assume that it's a bad idea in packages in contrib and non-free too. If one wants to vary from that, the reason should be made very clear indeed. I don't believe that Praveen has provided any real justification for needing network access, beyond his opinion that policy allows it. I suspect that in the particular case of using rollup, it is even worse than Simon McVittie eloquently describes in his mail to this thread. A quick read of rollup's changelog shows that they have had about 30 releases since July, that they've recently had a major refactoring, and that every release since that refactoring has involved fixing that refactoring. They had a release within a day of Praveen's changelog entry for the package, so it's not completely obvious which version of rollup would have been used for the package build, but chances are that he used one version, and that within 24 hours nobody, not even Praveen, would be certain of being able to reproduce that package because it would then be using a new version of rollup to do all the work. They've had another release since -- more fixups for the refactoring. I'm astonished that Praveen thinks it is sensible to build on these shifting sands. My astonishment is then only magnified at every step: o When it is pointed out, still not realising the folly of this. o Running to policy, looking for excuses. o Blaming ftp masters for not noticing these flaws. o Insisting that the TC needs to be involved to fix the mess Should we really try to make policy forbid all the foolish ways in which one might try to assemble a package, in order to ensure that there is nowhere for people to hide in policy? I think not. It would seem much more straightforward to remove the upload rights from people who insist on repeating this sort of behaviour incessantly. Praveen, please don't do it again. 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
Accepted ssh-askpass 1:1.2.4.1-10 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 02 Sep 2017 01:14:40 +0200 Source: ssh-askpass Binary: ssh-askpass Architecture: source amd64 Version: 1:1.2.4.1-10 Distribution: unstable Urgency: medium Maintainer: Philip Hands <p...@hands.com> Changed-By: Philip Hands <p...@hands.com> Description: ssh-askpass - under X, asks user for a passphrase for ssh-add Closes: 568724 577485 873807 Changes: ssh-askpass (1:1.2.4.1-10) unstable; urgency=medium . [ Helmut Grohne ] * Rewrite build system as autoconf (Closes: #873807) . [ Philip Hands ] * improve the package description (Closes: #568724) * drop the x11- from the name in the man page (Closes: #577485) Checksums-Sha1: 64ab875129ce334f0ef69ddae27a1c3c311dffb9 1866 ssh-askpass_1.2.4.1-10.dsc 78c992951685d4dbffb77536f37b83ae2a6eafc7 29229 ssh-askpass_1.2.4.1.orig.tar.gz 35e8a930e9bd243c8a647c90dc946822fc38e65d 5540 ssh-askpass_1.2.4.1-10.debian.tar.xz 94cf860b7ebfe071d721ac1f4f7e5c7be900280b 35922 ssh-askpass-dbgsym_1.2.4.1-10_amd64.deb f021739515fe4b15ec3746bf851c1661a89ed22a 6372 ssh-askpass_1.2.4.1-10_amd64.buildinfo bb36e40cbd712b065c8dc3c5847ab234ac10c85a 31548 ssh-askpass_1.2.4.1-10_amd64.deb Checksums-Sha256: d70eafef19ed0c019f268e1f5f7e464c1a1d9d2ac65c98372b088573269a705a 1866 ssh-askpass_1.2.4.1-10.dsc 620de3c32ae72185a2c9aeaec03af24242b9621964e38eb625afb6cdb30b8c88 29229 ssh-askpass_1.2.4.1.orig.tar.gz 503092cd633cc731d9f568b165ac800d329f6f6b5085e728de01be51baed1c28 5540 ssh-askpass_1.2.4.1-10.debian.tar.xz 0a434fffcef2374b4d1da8b893316ec9b4df0c59a1a89891b1051e4efc633ed5 35922 ssh-askpass-dbgsym_1.2.4.1-10_amd64.deb cd8609bd191c8f842e954c5836a65b7d21dfd5eda9c62e08cb8c3a9f0d924dec 6372 ssh-askpass_1.2.4.1-10_amd64.buildinfo 503a5b579e38d8a293a71becb0127dbd25a8b4208490c7d6b0123d94c2130169 31548 ssh-askpass_1.2.4.1-10_amd64.deb Files: bac62a47d9179cbb42a63eb93ef28a96 1866 net optional ssh-askpass_1.2.4.1-10.dsc 8f2e41f3f7eaa8543a2440454637f3c3 29229 net optional ssh-askpass_1.2.4.1.orig.tar.gz 413dba8a476429e412a2b490ad54f7b7 5540 net optional ssh-askpass_1.2.4.1-10.debian.tar.xz 5dddf155216e9805b53cb971fdbdbf0c 35922 debug extra ssh-askpass-dbgsym_1.2.4.1-10_amd64.deb b1c8badbe7c4eb339beb0110b3a20adb 6372 net optional ssh-askpass_1.2.4.1-10_amd64.buildinfo 84b743cb600e8713a64035c3785445b7 31548 net optional ssh-askpass_1.2.4.1-10_amd64.deb -BEGIN PGP SIGNATURE- iQJDBAEBCgAtFiEE3/FBWs4yJ/zyBwfW0EujoAEl1cAFAlmq3mcPHHBoaWxAaGFu ZHMuY29tAAoJENBLo6ABJdXAbuQP/i0i7ZGLPRcLfV4C/hJPG9wC9tTMXiGdQuj1 mrklkFtSia6atV0zfzxEQijy5IZTQlZJ0ncVM2tZye/zSWtS9y2b+fpUln6h7L6k JHDqR+teo+JKCXNNgy7RlqgHERTh2YCyOjRm5RBzDYrp2BbzH5MmIV1TQgb1wCYw p6bm4HqmG7byIDNaj0DG99m933tQpButLvTpEtgSwBpmgnRFEbuOkQqMzFCi8BAE 83VF7+NmhHLZB8F63DddsqT2OjK3p4KbZP1iIkI3JatXsZLhsCn+x7nfg/uXDLdl MzPPOYsDG0pLJGslN1HXQgRDUgbjMxR36YYvbe8o6I8OdqolQcSbA1d15tdn52l8 wV/q9NJ+OllvCdXYhvIeanHXE5kfD0jgIRFlO8LKf5j5Wsk8RHXPLHkAnTnW3jE3 28jqfCGLbdAv9VEqE9eafH31ETQGXZkGFPurY3ubKQEpQDbj8UjEEFRGb/d0a92P qFQZRRWVH1ie2b0gX5FnDIaXdzwSsJXyidDlEz39zi+oXmIzQDaSCcWwN3HyWaTF btMeqfKfSAX8a6YKkBM8YoT7EiTxrdM7VRFZbiGHPK1bIRSeAljoxWPh3BHuOvkE znLOCWzvF1EZp1RQ7GdJ5auYrjXvyAp/eYNZYNotzwlQ6Jr5lGHPIQj+x7RjuB3Y EpT6TkEO =23Ey -END PGP SIGNATURE-
Re: Single Sign On for Debian
Michael Lustfield <mich...@lustfield.net> writes: ... > Using Gitlab (or any VCS) as the user db for guest accounts means adding a > dependency that could block future upgrades... kinda like now. This is not a > future-proof design and will come at a future cost. I suspect that Alexander's intent was just to avoid blocking the gitlab setup on having some SSO solution in place. If lemonldap-ng can make use of gitlab's guest data initially, then that lets the two things be setup independently. Once lemonldap-ng is shown to do the job, I doubt it will be a big task to transfer authority for the guest data into lemonldap-ng's control, and then have gitlab use lemonldap-ng as it's source of that data. 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: Call for volunteers: FTP Team
Nicholas D Steeves <nstee...@gmail.com> writes: > On Fri, Aug 18, 2017 at 12:04:26AM -0300, Henrique de Moraes Holschuh wrote: >> On Thu, 17 Aug 2017, Joerg Jaspert wrote: >> > On 14767 March 1977, Jonathan Carter wrote: >> > >> it has been quite a while since the last call for volunteers, so here is >> > >> an update: Yeah, we still need people, and we want you. Well, that is, >> > >> if you are a Debian Developer, for this. If you are not and want to >> > >> help, read the last paragraph please. >> > > If someone hypothetically joins, are they allowed to rename the FTP team >> > > to something that doesn't include "FTP"? >> > >> > GopherTeam? >> >> archive team, really. But where's the fun in that? >> >> funmasters, maybe? it is only a two-letter change... > > I would like to propose a one letter change FTP -> FTW > > For The Win Team is also For The World ;-) > > Unfortunately For the World Masters seems...erm...slightly...? > > ...Well, in keeping with the Toy Story theme, FTW Masters is > worshipped by the Squeezes (packages alien to the archive) and at the > time of a "Win" a package new to the archive is selected as for the > "World". Finally, New Maintainers tremble with trepidation at the > power of The Claw, as it is known internally. I like "The Claw" -- responsible for picking up NEW packages, and giving them to the kids, or dropping them. 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: Subject: UMASK 002 or 022?
Paul Wise <p...@debian.org> writes: > On Wed, Jun 28, 2017 at 1:11 AM, gwmfms6 wrote: > >> I'd like to know why giving the world (Other) read access is even under >> consideration. If user wants a file to have Other readability this should be >> on the user to set it, but it should not be the default. > > I expect for most Debian deployments this isn't that relevant, since > most are either servers with no real users or single-user systems with > no guest account. > >> What is the justification that every user be able to read everyone else's >> documents? > > This decision was made in the mists of time and has never been questioned. > >> This discussion should be on whether to set a default UMASK of 077 or 027. > > I think the appropriate default umask is 077 due to the possibility of > some sites not naming the primary group of each user after the user. 077 is poor choice of default given that we decided to have users in their own dedicated group precisely to allow more generous group permissions, and if someone decides to deviate from that policy they need to take care of the consequences of their actions. In case anyone is wondering why we have users in their own group is it to allow one to create shared group directories, with the group s-bit set, so that anyone in that group can create files in that directory. If one has a 077 umask, that results in files in s-bit directories being created that only the creator can read, which is almost certainly not what you wanted. To fix that, one sets a umask of something like 027 or 022 or 002 depending on your needs, but on traditional *nix systems all users would generally be in a users or staff group, so you just gave overly-permissive access to your home directory by doing that -- hence the dedicated per-user groups. > That said, 027 would probably be a reasonable default too since most > sites do not do that. I think 027 is much easier to justify, is seems likely that anyone that prefers 022 over 027 is more likely to know why. 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: Too many Recommends (in particular on mail-transport-agent)
Adam Borowski <kilob...@angband.pl> writes: >> > dnsmasq-base: lxc >> > * BAD: how often are you on a network without a DNS server? >> >> Your question here indicates to me that you've missed the point of this >> dependency entirely. lxc uses the dnsmasq program (not service, hence >> -base) for *DHCP* for containers on the container network. > > I do use lxc quite heavily, usually choosing IP addresses within config > files but sometimes using DHCP. And it seems to work just fine without > dnsmasq -- thus, unless I'm missing something, it's not something that > "would be found together [...] in all but unusual installations". I suspect that you are bridging your containers straight onto a real network, which is then providing the DHCP, whereas the default arangement for naive users is to have a layer of NAT or some such (I'm not 100% sure, because like you I never use that option either, but I'm aware it exists). I also suspect that if you have configured lxc as you have, dnsmasq sits unused on the disk, which is not something to object to if it means that people using the default setup get something that works -- which they would not get if you had your way. 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
Accepted rootskel 1.123 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 01 Apr 2017 11:50:30 +0200 Source: rootskel Binary: rootskel Architecture: source amd64 Version: 1.123 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team <debian-b...@lists.debian.org> Changed-By: Philip Hands <p...@hands.com> Description: rootskel - Skeleton root filesystem used by debian-installer (udeb) Changes: rootskel (1.123) unstable; urgency=medium . * S02module-params: avoid registering options for non-modules (#853855) The non-modules list is based on the kernel-command-line(7) manpage. Checksums-Sha1: 50f448e41dd1d45e3a1f6acf366250617a65bd79 1704 rootskel_1.123.dsc 46730b2a514fc54c966d3e791fe42933d21c4e8b 31564 rootskel_1.123.tar.xz fea238c94b017d0f2ffed301009d46c589989d3a 5277 rootskel_1.123_amd64.buildinfo 44d389e83a8bda545bd7034b38646759ba979d33 9142 rootskel_1.123_amd64.udeb Checksums-Sha256: 7cf5990e2c5af6789d9c6ad9d839840396554db53f4d4d9b2fa80be4fba4ba74 1704 rootskel_1.123.dsc c470a73a9e45683f05043efdef54e465461fa837e23656a58fe984f0adcb1fcb 31564 rootskel_1.123.tar.xz fe06e418c167ae1efa0449d38d6495bf07d0ba79a1e597bf3d6ccbdca52baa23 5277 rootskel_1.123_amd64.buildinfo f2ea7fef323ae33610bb2df54e761ac97714e4c9320a149edf2bb1da09273691 9142 rootskel_1.123_amd64.udeb Files: 7e4f40e1943b716f7a0559299e7954e7 1704 debian-installer standard rootskel_1.123.dsc 120be2d8ec37d3c052b2e24b0af134ff 31564 debian-installer standard rootskel_1.123.tar.xz 8e05476917a7304f091de781a7d786e4 5277 debian-installer standard rootskel_1.123_amd64.buildinfo 1c4561748253adeafc477c64fb8adace 9142 debian-installer standard rootskel_1.123_amd64.udeb -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEE3/FBWs4yJ/zyBwfW0EujoAEl1cAFAljfe3QACgkQ0EujoAEl 1cBGDRAAmUAGLgpwLjnzo+GRZFAemJF7b0utZzEQ3uHBJiE7z8Y/Mzbvrnv3u6bL iZAIWq24E1ssXWGYSh7ZRNfVzNi1KXhvTXATpRFvDRflKCl7+n/H90Zhhr56ocpF neVxBcMEnmRsQtVltteQy2dt4lPJHVHe6+5L1XCgcsCaeGu6d8JozHEZndf7RNuq GwPpGFR8iylXGftkNaKlQLLP4NdWFVM6ay9S+BLXjI5hql+TmbOSyQtofPS2ccYZ OCdCDVBFYb8ixH/IBY2agGh86bG9rBC+HOICvit1UO2PGYIOmOEeWd030xsV23uD 4sfGMYbu31dg/g+3hnLpN2BFvOc7zUNgM2/3Hhjs2WSHnibi+ltJhfwV3lBuZkZf uOwPZpBlzuzxzhRXbY4AO/KblMaT0VpLZQH3Pzc1nqkWfB8LfgbPG+R7umwT2wXH v3OLJidvVrKQ0Hd5RLrdC2o02yKCO2HJnB2LLVJnSHkOm2Hx3M7mVQMu7GFjPBTA HiKHA36EI9vVkw7+joOknIggC8fHvYmn46e5KdV9E4qCTHF9QQ5zOBhU0zb1SDFW +j5eHYLCbZHoXMjdRjsT+b5ADZ8I1fcHZoqFh9dNB9JcDaGQcNz2nF2vAAqThDv6 w87Rphmo0f1C8SK00PC3TAAg4BaTj/A5ev4JjUMUI+ZTQmRbJoA= =ZpnC -END PGP SIGNATURE-
Accepted debian-installer-utils 1.119 (source all amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 01 Apr 2017 11:56:13 +0200 Source: debian-installer-utils Binary: di-utils-shell di-utils-reboot di-utils-exit-installer di-utils di-utils-mapdevfs di-utils-terminfo Architecture: source all amd64 Version: 1.119 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team <debian-b...@lists.debian.org> Changed-By: Philip Hands <p...@hands.com> Description: di-utils - Miscellaneous utilities for the debian installer (udeb) di-utils-exit-installer - Exit installer (udeb) di-utils-mapdevfs - mapdevfs utility for the debian installer (udeb) di-utils-reboot - Reboot (udeb) di-utils-shell - Execute a shell (udeb) di-utils-terminfo - Terminfo entries needed by newt/slang in debian installer (udeb) Closes: 853855 Changes: debian-installer-utils (1.119) unstable; urgency=medium . * fix: propagate dot-containing options to target kernel cmdline (Closes: #853855) Checksums-Sha1: 5577e89ae9de2dfae5504e90b719cb2f51f832f8 2234 debian-installer-utils_1.119.dsc 89a8482b0eebc78e3677011aa95eec4451e0d725 97424 debian-installer-utils_1.119.tar.xz ae1c1483d1e4114d2ec2a4932b9e72a82eb1afd5 6875 debian-installer-utils_1.119_amd64.buildinfo 6044a56b609c23fe848dcccb13c6076fe57c1123 2848 di-utils-exit-installer_1.119_all.udeb b5d4350429c4af0826831a572b48084a87a7d5c4 2380 di-utils-mapdevfs_1.119_amd64.udeb f223e05b76f0201346bb91b368c5ccb757d9befe 10110 di-utils-reboot_1.119_all.udeb 2e2599503c4205438bc4a15f04b5b8f3ae8cd4a5 22344 di-utils-shell_1.119_all.udeb cab02e2505c554767672865893d699dbcac6c802 2796 di-utils-terminfo_1.119_amd64.udeb 64208646d929c1a65c9709216146c066de63183d 33878 di-utils_1.119_amd64.udeb Checksums-Sha256: 6406a90dcfc37d67caa83f47a3ce77a4018314381bf4e7b7b706a69eabd91988 2234 debian-installer-utils_1.119.dsc f92d6d0f307d4508e3a228e548e2ff4d0d961931640bcfa978460a20c9b8233d 97424 debian-installer-utils_1.119.tar.xz 20515d52ff85737ae880bd7375db682b10699ca0eb1e6eb24b40001a802a6d58 6875 debian-installer-utils_1.119_amd64.buildinfo 84ae1e40f7dd0b0449fa9b6aadc61d8ac90e8e3078ac580cb69cc1e901be1e14 2848 di-utils-exit-installer_1.119_all.udeb daf12b0ca4a5b6cbc73368c7c4a8c7698b28492307df7f3f1a90be9ddd376dad 2380 di-utils-mapdevfs_1.119_amd64.udeb 81468054c0da2e464de30088c2452709048263901c83e25e9af827f6f632604b 10110 di-utils-reboot_1.119_all.udeb 0dbccdb32af63545a1f8befe77036165e6a1a11265406af17418625972e93051 22344 di-utils-shell_1.119_all.udeb d80a23a7ec55939d22ca1b42a471890fc181f8e445c7ea7e9092a68b38b51136 2796 di-utils-terminfo_1.119_amd64.udeb 587626f487f0e56827ea88632a307e6be2e6fe2feeb7930d732182a22c2e 33878 di-utils_1.119_amd64.udeb Files: 22067309ead980051456f6c7466bccfe 2234 debian-installer standard debian-installer-utils_1.119.dsc adfdd0df9e7e3b45b2f60557e07abb87 97424 debian-installer standard debian-installer-utils_1.119.tar.xz d7cbd58ff0a1f1253c2a462ca22c4585 6875 debian-installer standard debian-installer-utils_1.119_amd64.buildinfo c5ab720425fa8112d1b137faaa41f724 2848 debian-installer extra di-utils-exit-installer_1.119_all.udeb a8833d4a0e9e432eac8bda824c67fb5b 2380 debian-installer standard di-utils-mapdevfs_1.119_amd64.udeb 2b5b2b0f46993f63ee29c5707b4d517f 10110 debian-installer standard di-utils-reboot_1.119_all.udeb 58eda6132294c073b34aae18cf10df4e 22344 debian-installer standard di-utils-shell_1.119_all.udeb c36a918718a5dcc0bfe36ba8d83b34ff 2796 debian-installer standard di-utils-terminfo_1.119_amd64.udeb 531f1031a66366774c4b62df8b2514e1 33878 debian-installer standard di-utils_1.119_amd64.udeb -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEE3/FBWs4yJ/zyBwfW0EujoAEl1cAFAljfe80ACgkQ0EujoAEl 1cAUDg//Yb0T1Uc/F+LgEz/Ro3qsPinBcFy+skMmvX7QFls9o9rpXkXMPAY7lH4k WizKiLnrkwhBWxX46tsDK4ssJzE+e9Aypq/NX5MBBeKkOnHPuhaoK/9VwSws0cdN DcyH6VeKy3Fkrtt+BP0Q81QaD5wy1qcfUSnPiafjr/G8in847jtBtTwJGg94W6xS yA7aVHtqxRyD+N2sDNj/E8absHrYh7mMzPPVHnHDKrBnSVkkg3TjdpL8ZdfqQO1w m1T50lsH1Y+I9bfCn+ZIOCwHY52dRu2YQl/ihVI7TggyPJUZRmHAlSDiZFDpfYX7 BHN3zgWGd/dHIeYKCpnBYsFdRZkSdvya7lexY4zcheZ6ThhixhqEX5IJ8+G6bSZ1 JMOWSSDP1tKbcvdE6E6qZMGhDh9KpKsa8PCUVj/9Vzm/YeBc9QItdrwDiIEsPsOw BB0Q5jK0dU/mVnSplsbOPR1rOokB2U5M2YLz96HPlqbTLifwFyVpXwiwNMRp4HTq bv3XGd2JhCgGkbIwvLvozSwLkl1nSU2YPZKV2E0EkDOw/8TpoGdHdLaO/hhb8nd1 2rYkAVDtUITl8gJ7KCgIphopfwEMIUMcKDfZGnBlYSNTPWz1EmG6Hf3dOciQqBiZ vR/b+8zX43AfwBvJc/vufkN3QawZ4jWC7royCFbrAX+JiV1oA3k= =g8KA -END PGP SIGNATURE-
Re: System libraries and the GPLv2
Carlos Alberto Lopez Perez <clo...@igalia.com> writes: > On 30/03/17 21:29, Don Armstrong wrote: >> On Thu, 30 Mar 2017, Carlos Alberto Lopez Perez wrote: >>> * License Must Not Contaminate _Other_ Software >> >> A work which is a derivative work of another piece of software isn't >> merely distributed alongside. >> >>> Shipping a collection of software on a DVD doesn't make any of this >>> pieces of software a derivative works one of the other. >> >> Precisely. It only has bearing on whether the system library exception >> to derivative works applies. >> > > It should apply. > > Fedora and RHEL ship also DVD images, and they do use this system > exception clause of the GPL for linking with OpenSSL. Perhaps they have decided to ignore the bit of the license that says: "unless that component itself accompanies the executable." but I think it is more likely that they've had their lawyers look at each particular case that they wanted to include in their distro, in order to assess how realistic it is for there to be a problem with the result, and how painful it will be to fix if there is a problem. If we were to do a similar assessment, then we'd be asking the lawyers different questions, because we also care about how likely it to cause a problem for any of our downstreams (and their downstreams, etc.) or any of the users. RedHat are also in a position to offer indemnity against legal problems caused by using their distribution, if they want to, whereas we can only try to avoid the problem. So, pointing at the fact that RedHat has on occasion decided to violate the license in this way does nothing to prove that the violation does not exist. Nor does it make the exception to the exception go away, and we clearly are causing the "component" and the "executable" to "accompany" one another if installing a binary by whatever means causes OpenSSL to automatically be installed because of the dependency. I really doubt that any court of law will be particularly interested in the mechanisms that achieve that effect, so it's not just a case of making sure that the two things are not on the same DVD. Cheers, Phil. P.S. I am not a lawyer P.P.S. Does anyone really expect a consensus to emerge where we decide to ignore the exception to the exception across the board without consulting lawyers? I think there are several people in this thread (myself included) that have demonstrated that they're going to argue against such a consensus. That being the case, it's not going to happen, so repeating the same justifications for why there is no problem does not seem even slightly productive to me. -- |)| 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: System libraries and the GPLv2
Carlos Alberto Lopez Perez <clo...@igalia.com> writes: > On 30/03/17 03:11, Clint Byrum wrote: >> Excerpts from Carlos Alberto Lopez Perez's message of 2017-03-30 02:49:04 >> +0200: >>> On 30/03/17 00:24, Philipp Kern wrote: >>>> On 03/29/2017 11:10 PM, Carlos Alberto Lopez Perez wrote: >>>>> So, the best case situation (IMHO) would be that a lawyer tell us that >>>>> Apache 2.0 is also compatible with GPLv2-only, and that we stop playing >>>>> the game of being amateur lawyers instead of software developers. >>>> >>>> But that's not how the law works in the US. Without actual litigation >>>> and precedent, the most you'll get is a risk assessment of getting sued >>>> and your likelihood of winning if so. :) >>>> >>>> Kind regards and IANAL >>>> Philipp Kern >>>> >>>> >>> >>> Right. That is how it also works in Spain, and I suspect that in many >>> other countries work the same way. >>> >>> I understand that Debian wants to take a position of zero (or minimal) >>> risk, and I also understand the desire to respect the interpretation of >>> the FSF about the GPL (they don't think this two licenses are compatibles). >>> >> >> I believe that this is a fundamental difference between RedHat and Debian. >> >> RedHat is going to do everything within the law and inside their values >> for a profit. Their values don't include a strict adherence to the wishes >> of copyright holders, but strict adherence to the law. >> >> But our values do include respect for copyright holder rights. So while >> we can probably get away with this legally, it's been decided (a few >> times?) that without the GPL licensor's consent, we can't in good faith >> produce a combination of OpenSSL and a GPL program. >> > > Just a simple question: > > Do you (or anyone else) _really_ think the copyright holders of the GPL > program in question had any intention ever of not allowing their program > to be used along with OpenSSL, when they where the ones implementing > support for using it on the first place? Sorry, but people's intent is not sufficient. Let's we decide that we're going to ignore a license, because the author's a jolly nice person who obviously wasn't concentrating when they chose the license. We thus inflict this license violation on our users, our downstreams, and their users. Some of those users might then build their infrastructure upon that software, meaning that changing it could be very costly, and those users might be wealthy enough to be interesting to copyright trolls. Then the copyright holder dies and their estate passes on to someone that wants to maximise its value, so they sell the copyright to a copyright troll, who then goes around threatening to sue for the GPL violation, offering an explicit exception ... for a fee. I think our users expect us not to put them in that situation. What is the huge upside that makes it worth forcing our users to take this risk without their explicit consent? 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: Non-free RFCs in stretch
Josh Triplett <j...@joshtriplett.org> writes: > Iustin Pop wrote: >> On 2017-03-05 12:41:18, Ben Finney wrote: >> > Sebastiaan Couwenberg <sebas...@xs4all.nl> writes: >> > > I'd like to see a compromise in the DFSG like #4 for standards to >> > > allow their inclusion in Debian when their license at least allows >> > > modification when changing the name or namespace for schemas and the >> > > like. >> > >> > Since that does not describe the license granted in these documents, I >> > don't see why you raise it. >> > >> > On the contrary, I would like to see the license granted in these >> > documents changed to conform to the DFSG, and then they can be >> > included without violating or changing our social contract. >> >> I have to say I lean more on practicality side here, and I don't really >> see a need or reason to have standards documents under the "free to >> modify" clause. > > Then they can stay in non-free along with all the other things under a > non-free license. We had a project-wide decision more than a decade ago > that the DFSG applies to *everything* in main, not just source code. I presume this issue arises because people (myself included) dislike the fact that in order to install some RFCs and/or GNU documentation one has to flick a switch that also opens the door to some thoroughly proprietary software. Of course there are several lines that could be drawn in a variety of places, but it might be nice to have the ability to only enable some subset(s) of non-free in one's sources.list (without having to specify a lot of fragile pinning) I suppose it might be possible that we (as a project) could agree to some of these subsets being easier and/or harder to enable, and thus allow the FSF to feel more cheerful about the way we look at the world. 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: SPAM
Christopher Clements <bcn...@gmail.com> writes: ... >>That then provokes a small fraction of the victims to shout at us, >>because they don't know ho to read headers. >> >>That is what you are seeing. > > Are you saying that these messages were not sent to > <debian-devel@lists.debian.org> and relayed to subscribers, but were > instead forged to look like they were? [I note that I missed this question earlier.] Yes, the message that Illuminati got (which he subsequently replied to) almost certainly didn't go via any debian infrastructure at all (if the similar messages I got were anything to go by, which I think they are). However, because the spam meaasges are created by copying most of the headers from a genuine list mail, when you reply to such a message, it turns up on our lists, and looks like it might even be a reply to a real thread (until you notice that the body of the message they were replying to has never previously been seen on the list). 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: SPAM
Christopher Clements <bcn...@gmail.com> writes: > On Sun, Mar 05, 2017 at 09:55:14AM +0100, Philip Hands wrote: >>Christopher Clements <bcn...@gmail.com> writes: >>> On closer examination, I think you are correct in saying that the >>> replies are written by the spammer as well. >> >>On closer examination of what? > > The "To:" field. Ah, yes, a very common misconception. All the headers that email programs normally show you are part of the (trivial to forge) contents of the message. You need to look at the (normally hidden) Received: headers (as well as others like Return-Path: and Original-To: if your mail server adds them) to get any information you can really trust. I think it's instructive to contemplate the way this worked before email. If one received a ransom note (such as seen in a black & white movie, staring Humphrey Bogart say, where the letters were cut from magazines), one would not pay much heed to the salutation and signature in the note (particularly if also cut from magazines). Instead, you'd want to look at the postmark on the envelope, and the smudges made by the typewriter that was used for the address. It is a real shame that it has been made so hard for normal users to see these evidence-bearing headers on emails. It's as though everyone has a butler who insists on shredding the envelopes before handing you the morning mail -- it makes the vast bulk of people very vulnerable to being duped. 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: SPAM
Christopher Clements <bcn...@gmail.com> writes: > On Sun, Mar 05, 2017 at 12:42:50PM +1100, Ben Finney wrote: >>Christopher Clements <bcn...@gmail.com> writes: >> >>> On Sat, Mar 04, 2017 at 03:36:58PM +1100, Ben Finney wrote: >>> >I think the best explanation is that the entire message ??? complaint and >>> >quoted part ??? were composed and sent by the spammer themselves. >>> >>> Oh, the "original" message is seperate, I just replied to a reply. >> >>That doesn't contradict my explanation; I think both messages are >>composed by the spammer. > > Sorry about that, I misread you and thought that you thought that there > was only one message. > > On closer examination, I think you are correct in saying that the > replies are written by the spammer as well. On closer examination of what? The headers of the mail you're apparently complaining about look pretty genuinely like the mail really did come from gmail, so are you suggesting that 'The Illuminati <trainjohnso...@gmail.com>' is the spammer? That looks like a genuine person -- I cannot imagine a spammer creating supporting evidence for a spamming account. e.g.: https://twitter.com/trainjohnson87 Note that that twitter account appears to belong to someone called Anthony, which matches the salutation in the Spam that he then replied to. The level of maturity shown in his reply appears to be in line with someone that is obsessed with minecraft. > Perhaps they simply want to waste space in archives? > Not much of a motive/goal, but I get the feeling that the perpetrator > doesn't have much of a life to start with. It seems very plain to me that the spammers are recycling headers from our list mail on the basis that gmail's anti-spam will have learned that as HAM, and are so are more likely to let that pass through. That then provokes a small fraction of the victims to shout at us, because they don't know ho to read headers. That is what you are seeing. If anyone knows people that fight spam at gmail, I suppose that they might want to treat listmail that comes from an unusual IP address with great suspicion, but I don't think this is in any way limited to gmail. I guess we could help the mail servers of the recipients of the initial messages make that decision if we did SPF for debian.org, but I guess that the lack of SPF probably indicates that this is very hard to do with our distributed setup. 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: Bug#829076: general: Random freezes but the mouse can still move
The Wanderer <wande...@fastmail.fm> writes: > On 2017-02-26 at 09:01, Lars Wirzenius wrote: > >> * John Cuffs tells Lee to "shut the fuck up", and quotes a spam that >> isn't visible (anymore?) in the bug log. > > Just to note: this almost certainly wasn't actually addressing any of > the thread participants, and also probably wasn't posted by John Cuffs. > > This is a standard form of spam that I've been seeing on mailing lists; > my assessment of the form indicates that the "original" spam message was > never actually sent, the spammer is instead sending a fake "reply" which > quotes the spam message and has headers (etc.) as if it were a response > by J. Random Netizen to a message already posted in some random > thread. I think you are mistaken. Having seen both the noise on lists, and having on a couple of occasions also received the same (pre-reply) directly to me, I would think that what happens is that the spammer lifts the headers from a legitimate list mail, and replaces its body with their drivel. The (often rude) replies we see on the lists are almost certainly from misguided folk who look at the headers and think that they have been subscribed to one of our lists, and probably think that our lists are a mechanism for sending spam -- not realising that the mail they got actually never touched our servers, but simply copied the headers from a genuine message. I presume spammers are doing this because it is likely that a lot of people have our list/bug mail as a significant contribution to the HAM corpus in their statistical filters. Sadly, I'm not sure there is much we can do to stop this, since it's all happening on other people's systems, so the first we hear about it is when someone becomes confused enough to reply angrily. 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: De-Branding of Icedove, reintroducing Thunderbird packages into Debian
Emilio Pozuelo Monfort <po...@debian.org> writes: > On 16/02/17 20:14, Adam Borowski wrote: >> Following good general practice and having the disk encrypted is of no >> help as they force you to enter your password, often with multi-year jail >> time (UK) if you fail to comply. > > Link? I think he's talking about RIPA, in which case: http://www.legislation.gov.uk/ukpga/2000/23/section/53#commentary-c19929351 Section 5A: up to 5 years for national security cases (which is pretty much anything these days it seems) or 2 years max otherwise. The "tipping-off" stuff is lovely too: http://www.legislation.gov.uk/ukpga/2000/23/section/54 I guess one might end up needing a lawyer to know if revoking one's compromised keys is something that will also get you a 5 year sabbatical. 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: node-tty-browserify_0.0.0-1_amd64.changes REJECTED
Pirate Praveen <prav...@onenetbeyond.org> writes:
...
> "This module is a dependency for browserify." is already present in
> the description. And short description says "tty module from node core
> for browsers".
That presumably makes sense to people that know what node is.
I'm somewhat aware what it means, having pondered quite a lot of these
ITPs, but it is pretty close to nonsense.
Someone that does not know what node is needs to decide if that should
be read to mean one of:
tty module from [node core for browsers]
or
tty module from node core, for browsers
or perhaps something else.
Having done that, they then need to wonder what a tty module might be.
Then again, they could try looking at the code, which astonishingly does
nothing other than throw errors about how none of this is implemented,
except in the case of the one function that does anything ('isatty')
which unconditionally returns false.
That being the case, one might have hoped for a description saying
something like:
stub version of tty, to (barely) satisfy browserify's dependencies
The description that you are attempting to defend has been lifted,
unedited, from the github repository.
I'd suggest that it was already misleading to the audience that it was
aimed at, which is not the audience it is now being misapropriated for.
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: Bug#854183: ITP: node-time-out
Shirish Togarla <shirishtogarla...@gmail.com> writes: > The link is https://git.fosscommunity.in/shirish/node-time-out.git That does not seem to include any history, which is a bit of a shame, Do you not have a clone of Mark Funk's github repository? BTW do you happen to know why he appears to have deleted his repository? If he's no longer willing to be upstream, are you happy to take on that role (which is what you appear to be doing by setting up a repo. and packaging it). Also, the description seems a bit strange: Simple setTimeout cancellation I presume this also allows one to set a timeout, as well as cancel it. If not, the package name seems rather misleading. 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: If you can't describe what the package is, you probably should not Intend To Package it.
Ian Jackson <ijack...@chiark.greenend.org.uk> writes:
> Adam Borowski writes ("Re: If you can't describe what the package is, you
> probably should not Intend To Package it."):
>> On Tue, Jan 31, 2017 at 12:17:29PM -0600, Gunnar Wolf wrote:
>> > Maybe adding a note stating 'this content is autogenerated and should
>> > be hand-reviewed', in all of the dh-make-*-enerated packages, would
>> > help?
>>
>> Especially when paired with an autoreject, yes.
>
> Maybe as well as a stick, a carrot or at least some words that might
> suggest useful things to wrote:
>
> [ delete as (in)applicable: This package is part of XXX system /
> used by XXX / needed as a build-dependency of XXX ]
As well as that, one could suggest that people add a paragraph about why
they wish the software to be packaged (as a comment that will not appear
in the uploaded package) and/or something about themselves if they're
new to creating packages -- It seems to me that they're more likely to
get useful feedback that way.
Also I suspect that some of the people creating recent ITPs are unaware
that their efforts are going to be forwarded to debian-devel to be read
by thousands, and will also be searchable in the BTS forever with their
name on it (along with any comments provoked -- positive or negative).
Some sort of warning to that effect might make devoting a little more
effort seem worthwhile.
BTW in the case of the node-* packages, I think they're being generated
by 'npm2deb'.
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: Worthless descriptions for almost all of the recent node-* ITPs
Hi Praveen, Having seen the unedifying thread on pkg-javascript I can see why you might be rather defensive on this subject, but this thread was intended as constructive criticism. The packages do actually need a long description to make it through the NEW queue, so this is really just about when that gets added. If that's done before submitting the ITP then it gives a better impression, and would also encourage people to suggest improvements. I've responded to a few of these ITPs and have found the responses I've received suggest that you've chosen your recruits well, so it strikes me as a shame that they are underselling themselves by submitting ITPs in this state. It would probably help if they also wrote a line or two after the descriptions about why they are packaging the package and/or any concerns they might have about the wording or packaging. Doing that is much more likely to attract useful suggestions than sending bare ITPs with only (often rather dubious) short descriptions. I'm tempted to respond to each of these people's first ITP with some suggestions, but you are much better placed to pass on advice to them, so I think it would be better if you did it. 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: nodejs 6.9 in unstable, manual transition, schedule
Jérémy Lal <kapo...@melix.org> writes: > 2017-01-06 12:53 GMT+01:00 Philip Hands <p...@hands.com>: >> Jérémy Lal <kapo...@melix.org> writes: >> >>> 2017-01-04 10:04 GMT+01:00 Andrey Rahmatullin <w...@debian.org>: >>>> On Wed, Jan 04, 2017 at 09:54:34AM +0100, Jérémy Lal wrote: >>>>> No answer yet, people are busy, and the number of concerned packages >>>>> is low (a dozen or so), should i just rebuild and upload them myself ? >>>> The transition freeze was on Nov 5. >>> >>> This is not very smart - i'm talking about something that will make future >>> maintenance and security patches easier, something that is easy to do >>> and that i can even do alone. >> >> Your "This is not very smart" comment made me react fairly negatively at >> first reading. It's easy to assume bad things about the old version's >> stability reading that, although that's presumably not what you were >> saying. > > I'm asking you to forgive me about that wording, it was driven by my > disappointment, > and the reason the package is in this situation is mainly my own fault > and lack of time. Nothing to forgive from my point of view -- you just happened not to be making your case very persuasively. Feel free to tell us all how there's no problem rebuilding/testing the thousand-odd node-* packages, or that they don't need rebuilding or testing, or whatever the case might be, such that people might be moved to agree with you. 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: nodejs 6.9 in unstable, manual transition, schedule
Jonas Smedegaard <jo...@jones.dk> writes: > Hi Phil, > > Thanks for looking into this! > > Quoting Philip Hands (2017-01-06 12:53:10) >> Jérémy Lal <kapo...@melix.org> writes: >> >> > 2017-01-04 10:04 GMT+01:00 Andrey Rahmatullin <w...@debian.org>: >> >> On Wed, Jan 04, 2017 at 09:54:34AM +0100, Jérémy Lal wrote: >> >>> i really think it would be best to have nodejs 6.9 in next debian >> >>> release. >> >>> That version is currently in experimental and i was about to upload it >> >>> to unstable, but i tried to do things right and prepared the addons >> >>> that need to be rebuilt and binNMUed, then opened a transition bug >> >>> #849505. >> >>> No answer yet, people are busy, and the number of concerned packages >> >>> is low (a dozen or so), should i just rebuild and upload them myself ? >> >> The transition freeze was on Nov 5. >> > >> > This is not very smart - i'm talking about something that will make future >> > maintenance and security patches easier, something that is easy to do >> > and that i can even do alone. >> >> Your "This is not very smart" comment made me react fairly negatively at >> first reading. It's easy to assume bad things about the old version's >> stability reading that, although that's presumably not what you were >> saying. >> >> Having looked into it a little, I found this: >> >> https://github.com/nodejs/LTS >> >> which shows that the current packaged v4 packages will drop out of LTS >> in April, and out of maintenance a year later according to this: >> >> https://hackernoon.com/node-js-v6-transitions-to-lts-be7f18c17159 >> >> Version 6, which Jérémy is suggesting should be our stable release >> version, has been in LTS mode since October, and will be in LTS mode >> until Apr 2018, then maintenance (presumably until Apr 2019). >> >> I suspect that in a couple of years time, that Node.js programmers will >> not be that much more impressed with v6 than they will be with v4, since >> both will be astonishingly ancient, but at least v6 buys us an extra >> year of usefulness. > > Until this point I thought you would summarize with a suggestion that we > get v6 included in next stable Debian release (i.e. a plea to the > release team to make an exception from their general rules). > >> I suspect that it might be better for all concerned if we simply >> encouraged people to use this via backports from the start, to avoid the >> problem of fast-moving projects getting preserved in amber by Debian. > > Do I understand you correctly that you recommend that we all tell our > users - e.g. in release notes - something like this: "We acknowledge > that the Nodejs included in this release is outdated, and recommend that > you avoid it: Please instead subscribe to our snapshot repository and > use the newer (but lesser supported) version from there."? I wasn't going as far as recommending anything -- I was just trying to cover various aspects of this in the hope that we might then discuss the pros and cons of the choices available before the release rather than drifting into doing something that doesn't really suit anyone very well. I don't know enough about the implications of upgrading to have any strong opinions about what the best course of action might be. It just struck me that to have v4 enter Debian stable just at the point that it drops out of Node.js LTS is unlikely to be the optimal choice. 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: nodejs 6.9 in unstable, manual transition, schedule
Jérémy Lal <kapo...@melix.org> writes: > 2017-01-04 10:04 GMT+01:00 Andrey Rahmatullin <w...@debian.org>: >> On Wed, Jan 04, 2017 at 09:54:34AM +0100, Jérémy Lal wrote: >>> i really think it would be best to have nodejs 6.9 in next debian release. >>> That version is currently in experimental and i was about to upload it >>> to unstable, but i tried to do things right and prepared the addons >>> that need to be rebuilt and binNMUed, then opened a transition bug >>> #849505. >>> No answer yet, people are busy, and the number of concerned packages >>> is low (a dozen or so), should i just rebuild and upload them myself ? >> The transition freeze was on Nov 5. > > This is not very smart - i'm talking about something that will make future > maintenance and security patches easier, something that is easy to do > and that i can even do alone. Your "This is not very smart" comment made me react fairly negatively at first reading. It's easy to assume bad things about the old version's stability reading that, although that's presumably not what you were saying. Having looked into it a little, I found this: https://github.com/nodejs/LTS which shows that the current packaged v4 packages will drop out of LTS in April, and out of maintenance a year later according to this: https://hackernoon.com/node-js-v6-transitions-to-lts-be7f18c17159 Version 6, which Jérémy is suggesting should be our stable release version, has been in LTS mode since October, and will be in LTS mode until Apr 2018, then maintenance (presumably until Apr 2019). I suspect that in a couple of years time, that Node.js programmers will not be that much more impressed with v6 than they will be with v4, since both will be astonishingly ancient, but at least v6 buys us an extra year of usefulness. I suspect that it might be better for all concerned if we simply encouraged people to use this via backports from the start, to avoid the problem of fast-moving projects getting preserved in amber by Debian. 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: Worthless descriptions for almost all of the recent node-* ITPs (was: Re: Worthless node-* package descriptions in ITPs)
Hi Praveen, I assume that all these ITPs are prompted by your crowd-funding effort. Today we have #850399 which plumbs new depths in that it has had both long and short descriptions trimmed from the body of the message. Please would you take responsibility for your packaging team by instructing them that it is simply unacceptable to have these packages with such useless descriptions. The fact that they all seem to be trimming off the FIX_ME that npm2deb includes for them, and are thus also removing the explanation of what Node.js is, seems like vandalism to me. Did you tell them to do that, or are they learning that from one another? TBH I find this whole approach rather worrying. Are you paying these people for their efforts? Are we supposed to expect them to remain interested in these packages when the money dries up? If not, what is the plan for providing maintenance for these packages for the time that they are going to be in stable? Cheers, Phil. P.S. While you're at it, I would suggest that you encourage your packaging team to contact the upstreams in order to discover whether they are happy for their current release to be preserved in Debian stable -- I can imagine that some of them might be unhappy with the prospect of having the latest release packaged, if there are bug fixes in the HEAD that they don't want bug reports about for the next 5 years. They could then push out a release quickly and you could package that instead. -- |)| 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: Worthless descriptions for almost all of the recent node-* ITPs (was: Re: Worthless node-* package descriptions in ITPs)
Christian Seiler <christ...@iwakd.de> writes: > On 01/05/2017 02:06 PM, Jonas Smedegaard wrote: >> Quoting Riku Voipio (2017-01-05 12:53:16) >>> Vast majority of users would only install this via dependencies. It's >>> hardly a node-specific problem that debian package searches output >>> large amount of packages that are not useful unless you happen to be a >>> programmer. >> >> ...and I agree that the issue is not specific to node-* packages, but I >> find it is quite common there. Quite likely due to recent inclusion of >> lots of packages, prepared semi-automated - as Philip pointed out very >> well. > > Could we maybe hide library packages from apt searches by default? I think you are perhaps misinterpreting my original subject line as saying that the node packages themselves are somehow not of interest. Sorry for not making that clearer in the original subject, perhaps the new one is better? I was only referring to the quality of the descriptions -- I don't know enough about node.js to comment on the merit of the packages themselves, nor their likelihood of being of interest to people. The example I picked out was laughably useless, but most of them are packed with field-specific jargon in the short description, and lack a long description. We (as a group) appear to be learning to treat "node-*" as a flag indicating that one does not need to pay attention. That would seem to be the reason that these ITPs mostly go without comment, and thus the package gets uploaded with the same flaws. I encourage people to take a closer look, and to comment on what they find -- I've only scratched the surface, and have had a pretty good hit-rate finding things (in addition to the missing descriptions) that are worth commenting on. 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
Worthless node-* package descriptions in ITPs
Hi Roshan, Please don't take this personally, you just happen to be the one touching the most recent remarkably meaninglessly described ITP for a node-* package -- I could easily have picked on one of the many other examples. I've Bcc:ed the bug to ensure that replies about this stay on -devel. Roshan <dn.rosh...@gmail.com> writes: ... > * Package name: node-pinkie ... > * URL : https://github.com/floatdrop/pinkie ... > Description : Itty bitty little widdle twinkie pinkie ES2015 Promise > implementation Can we stop the worthless descriptions in node-* ITPs please? What meaning is contained in the descriptions, is generally JavaScript/Node specific jargon that is pretty much meaningless to anyone else. This is because it is being lifted directly from the git repository description, where it is reasonable for the upstream to expect people to already know something about node, so that's the audience that is being addressed. That is not a reasonable assumption when applied to Debian users in general. To All Node.js packagers: Please proof-read and correct the short descriptions before filing ITPs. Also please fix the script that is generating these ITPs to add a long description that at the very least mentions that this is something to do with node.js, and what that means (such that people that are not interested in node.js can quickly determine that fact and move on). At present you are forcing that vast majority of our users, that have no interest in this software, to individually learn that they need to look out for the node- prefix, and ignore such packages. You are also giving the impression that all these packages are sloppily packaged, which makes one wonder if they are going to have any ongoing maintenance effort available for them (since it seems that too little effort was devoted to the initial packaging), which in turn makes one concerned about whether they are going to be fit for a stable release. 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: Can we kill net-tools, please?
Andrey Rahmatullin <w...@debian.org> writes: > On Thu, Dec 29, 2016 at 11:09:35PM +, Wookey wrote: >> Yeah I think that mess is why I've never felt any need to move away >> from ifconfig. I ran ip something a few times, went 'huh?' at the cryptic >> output and stayed with the rather more civilised /sbin/ifconfig. >> >> So it seem that the output does actually label things, but the things >> and labels look exactly the same. Would some colons really have hurt >> too much? >> >> i.e. mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 >> is really >> mtu: 1500 qdisc: mq state: UP mode: DEFAULT group: default qlen: 1000 >> >> Anyone think the latter is a tad clearer? I still don't know what a >> qdisc is or a default group, but it's a lot easier to find things I do >> recognise. Before this discussion I just saw it as a mysterious jumble >> of 10 things (after a set of things in CAPITALS that were somewhat >> mysterious too (what's a LOWER_UP, I wonder) - who knows what it might >> mean. > > Do you really think that > > wlp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 > inet 192.168.** netmask 255.255.255.0 broadcast 192.168.** > inet6 fe80::** prefixlen 64 scopeid 0x20 > ether e4:**:ca txqueuelen 1000 (Ethernet) > RX packets 66323088 bytes 90518262611 (84.3 GiB) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 18425793 bytes 2920636610 (2.7 GiB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > > is clearer than > > 3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group > default qlen 1000 > link/ether e4:***:ca brd ff:ff:ff:ff:ff:ff > inet 192.168**/24 brd 192.168.** scope global dynamic wlp3s0 >valid_lft 70216sec preferred_lft 70216sec > inet6 fe80:**/64 scope link >valid_lft forever preferred_lft forever > > ? There are two things that make it less clear. The thing you are looking for no longer starts at the first column there are no blank lines between interfaces If the numbers reach 2 digits then the interface name is indented at the same level as the rest of the data, which makes it slightly worse. I suspect that "wasting" a line feed between records would have made a vast difference to people's ease of adoption. Try comparing: ip addr to ip addr | sed '2,$s/^\b/\n/' I'm obviously already somewhat used to the normal output, so that now looks weird, but it is also triggering my pattern recognition from ifconfig a bit, so seems to have made me feel rather better about ip's output. I'm not suggesting we should actually change ip to have blank lines now, but if you still find ip's output confusing, perhaps trying it with the sed for a bit will allow you to transfer your familiarity from ifconfig. If you want an even more old school look without losing any info, try: | sed 's/^\(.*\): \(.*:\)/\1-\2/;2,$s/^\b/\n/;s//\t/' 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
Accepted cdebconf-terminal 0.28 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 21 Dec 2016 10:45:02 +0100 Source: cdebconf-terminal Binary: cdebconf-gtk-terminal cdebconf-newt-terminal Architecture: source amd64 Version: 0.28 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team <debian-b...@lists.debian.org> Changed-By: Philip Hands <p...@hands.com> Description: cdebconf-gtk-terminal - cdebconf gtk plugin displaying a terminal (udeb) cdebconf-newt-terminal - cdebconf newt plugin to provide a clean terminal (udeb) Changes: cdebconf-terminal (0.28) unstable; urgency=medium . * dependency ttf-dejavu-mono-udeb has been renamed to fonts-dejavu-mono-udeb Checksums-Sha1: 101fb32c509607d1dfc6eee97c7d5bb432f8eb43 1966 cdebconf-terminal_0.28.dsc e59c983dc4756cd22985106c0ecf88d71ae138f0 35700 cdebconf-terminal_0.28.tar.xz 9adaf26a35b149ab26d530b02f0ebcc9f71cb652 14860 cdebconf-gtk-terminal_0.28_amd64.udeb ee33bb1262450cea9ea02bbc6e3f2e57dd05f217 4612 cdebconf-newt-terminal_0.28_amd64.udeb 73ed6e6bf24ee92fa3880f4e301199b2a1132645 9564 cdebconf-terminal_0.28_amd64.buildinfo Checksums-Sha256: 7a8931040f3f87b68d9181e02dc71c36a12c638d5f60fbd6819da2a3a42e5a53 1966 cdebconf-terminal_0.28.dsc 045d9cbb9c6f80a0219243b5e5659ea9f6366def96ffb9bd8514fbb5130bacea 35700 cdebconf-terminal_0.28.tar.xz 67784554963ad44b5c4321d02f1d00aaac026dff37f06bb7d0118f9f54a71a1d 14860 cdebconf-gtk-terminal_0.28_amd64.udeb 0c6cff9a65ed3c74a9aa11dbe3f16f2469b21c1af07dd984cba9896ed71e2dae 4612 cdebconf-newt-terminal_0.28_amd64.udeb 77a8ed212bc26fedf1cd404aa96e0417b9f47d57eaa5d8c74ea4ecf37b4733cb 9564 cdebconf-terminal_0.28_amd64.buildinfo Files: 0242b7d5dc93745e29373fa7c195ccf4 1966 debian-installer extra cdebconf-terminal_0.28.dsc c3f63e9fefb504fb71298e3366f46589 35700 debian-installer extra cdebconf-terminal_0.28.tar.xz e28802345f0b26089776205d42c3f6e6 14860 debian-installer extra cdebconf-gtk-terminal_0.28_amd64.udeb c6b0e78d8958654d7148a7adc405028d 4612 debian-installer extra cdebconf-newt-terminal_0.28_amd64.udeb 4645f8a52b5a3ba20868c16163b65e0d 9564 debian-installer extra cdebconf-terminal_0.28_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEE3/FBWs4yJ/zyBwfW0EujoAEl1cAFAlhaUlIACgkQ0EujoAEl 1cB/BhAAkV3rnvmq5S3Da9oPfUymraX3eC8RPl6KOeqkR7SaId0nYKnn+fc/NYwt m0RhZ6mc80a0KTXLO3lfWY2Ea9zZuWR1oB+QhQbJG5oDEz5swsmADr1alSpi9pFm 08y1cV4ezRputUACZZvORDR+Hv1i0vPaoagB6fLWz8sv4dM6wrLj/nTtPdsZX/nR WTR7Sf7WfvaIeNZLo4nUqXp7OKffGt974f0fWg44sFhjtGh4jApnXf1xUiEJg4fv crhRT9CrrHeF/oNLtD54vNANzcPJA2P0t26fqegBofCDg3z8JRbNw+a5I58bdROV mPGGgbSVYzb5RDhhaoeTSFfktR0ZWEa/nkrzEKg3NvKTN03koO0WWEMwKnhaGKJ/ il22UU2m/eu8v6WfHbUDB8e4eGQAULgwlnv5CKE/lUb/8sNFpNGuYhuMjy/ZBy3I FNWTq2sDeJswVtzRNGA8SPdyBrTJI7aoTArfQboAB4LWWBOT3l8gaORGfVXCfbGI u5WAwdl62+vLlrLvO1R2T8/bku/c+8IGDLyncosu2Bdz9VLW3Wjli9BkKOIjkDYW gml6FoT88/QnbJTvFdN/Zc6xFPER93Q8L8sSACflWDLsUZd3UdYAl/6FLHKMqmBs ri+fBZPFrbIoS8hT+XhqJ1JBMl+Yd0VHXboj2freGX/pKRfP96U= =IRtp -END PGP SIGNATURE-
Accepted preseed 1.73 (source all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 24 Nov 2016 13:15:11 +0100 Source: preseed Binary: preseed-common network-preseed file-preseed initrd-preseed env-preseed Architecture: source all Version: 1.73 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team <debian-b...@lists.debian.org> Changed-By: Philip Hands <p...@hands.com> Description: env-preseed - debconf preseeding via environment variables (udeb) file-preseed - load debconf preseed file (udeb) initrd-preseed - load debconf preseed file from /preseed.cfg on the initrd (udeb) network-preseed - download debconf preseed file (udeb) preseed-common - common files for preseeding (udeb) Closes: 845326 Changes: preseed (1.73) unstable; urgency=medium . * make preseed_fetch pass all it's params onto fetch-url which allows one to add the new optional checksum as 3rd param * Update auto-install/defaultroot for stretch. (closes: 845326) Checksums-Sha1: 8b45afcf1435ae405a59d3c658d7efc175e70867 1867 preseed_1.73.dsc 4740d2fa1f1e55903bf26d613fa00a14f1bf8cb2 76144 preseed_1.73.tar.xz e4b4614cd893ab0cd4178cbf45c19841d42cd157 1820 env-preseed_1.73_all.udeb 95cc644fbfc2cb4a18477ee4bbca203616209e12 4134 file-preseed_1.73_all.udeb fb1c4adb96c8e93e0b652e4e681c7f55d86e58ed 870 initrd-preseed_1.73_all.udeb b7c82642efb5af5883ad1f0daf6b89a83f793b9a 30788 network-preseed_1.73_all.udeb 0c7dffbbe689966c6fa88a9ba2aaff393172e098 22110 preseed-common_1.73_all.udeb 6348eb55529cd297ebbe5437ada1ef51414c1699 5514 preseed_1.73_amd64.buildinfo Checksums-Sha256: f1cb14951ea900cef970bce72cb3a6c8f14926f811d55b3e3b88817c5b377891 1867 preseed_1.73.dsc 91ec612082f4cc01962d5d08f4bb934b47eb3a171cf9dcd68795e08ed8134e9d 76144 preseed_1.73.tar.xz a1e6c6b3b9042eafbac1a241928391b5a548f10b18320147c8e2521ce44b3166 1820 env-preseed_1.73_all.udeb 44764d8ac8ee77e26c17aa11fab0afa6f8609369a9a5075352e311f80549b281 4134 file-preseed_1.73_all.udeb e372dac33aeb279c8655036ef3935c15631bcdd900ac7245698b12298d484dca 870 initrd-preseed_1.73_all.udeb 33b23e005e2ef676bbc3b9ee4352ff0862f9ec2480d42ac8c9d976379c3b9a0a 30788 network-preseed_1.73_all.udeb cde015b85585900b9513ba96d7011366bb890674acc25485a44083c4902ad48d 22110 preseed-common_1.73_all.udeb 20b560258ce9761d2f527a05b372b51446c12d98165d95c92814ee0b7e7fb27d 5514 preseed_1.73_amd64.buildinfo Files: 0f06cefa9c38808e77bcd705d7ba9eb2 1867 debian-installer optional preseed_1.73.dsc 253669359f25d7d7123f63ebe55b1ba3 76144 debian-installer optional preseed_1.73.tar.xz a9c4fab8ea67dceff4fc54489d7abfe2 1820 debian-installer extra env-preseed_1.73_all.udeb 6d145ca6635833d9aad44e25d794dc8c 4134 debian-installer optional file-preseed_1.73_all.udeb e40b43147161cfbc52642d090acd20e9 870 debian-installer extra initrd-preseed_1.73_all.udeb a7eef09754f440c2cbe715f905c93282 30788 debian-installer standard network-preseed_1.73_all.udeb 69ee14d001b22300b081c552ffa90e5f 22110 debian-installer standard preseed-common_1.73_all.udeb 93c5bf06c8e1786c5cbbabbfd45e825c 5514 debian-installer optional preseed_1.73_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJYNtrEAAoJENBLo6ABJdXAngIP/jcSr1FuNMjwdEEl5zWJnqV8 LCRUGL0fadU7uIdw+7/UIoJqbN54A4gDucMwbnAGN3g9pQ1eN8zD2N5Y4845CdZ3 aAkrpLh8yTSN7Ce45DFiNKcNVF3fho6aN21DCOe47IBYXVdEVu+8SOz6XLh95VYb aKSMwkDmGaOQ5Dj8VFTW1lLFzGtLAcg/jVP2tC9ae/G0u4ovfFvdWl4ER5Auy5mo cKa8Ox1RgvJT4anxbZl4Mi5liQGCI3tsZ673YSBhE+flpq7p9yKG3KPw8hLCPUhe denMr9AN7BrxQbZsjAgey2qZnt5Vz82GjvPr925yvVgcFaKwQRpVY94zNblSQY57 A2l59dXuojrdOwQq/KL2cjqyM89WXzrvYjD7bGko1r4I1KY0yUt2PciuYLx4muSn dapodioQL1/eO1vRCuSeRebDQL1YIVaXo6fmEltMVJbn3BF7cQ+Fq4s8XSU9kqHI 2M4PrY/2AkMI6kJB5ERX7g30hWd0sNSz5LrhDqjfwhvDSwmzmHB8vo9x0GKFpt8k X0iYrQ29FfruX5zaxVCKtBOTwRV+Ln1AsQXtCiyYYcobejHv/hCz8GOaO6G8rO3d Hv8i+hvPnaDYoWsqlTP7sUBpmvR7VQjqH3EBvGQBFIZOoaA+JmqgvhBGrB/+FaBi BMjJn4AVE7tEFNeaoAUj =BYlm -END PGP SIGNATURE-
Accepted debian-installer-utils 1.117 (source all amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 23 Nov 2016 22:40:56 +0100 Source: debian-installer-utils Binary: di-utils-shell di-utils-reboot di-utils-exit-installer di-utils di-utils-mapdevfs di-utils-terminfo Architecture: source all amd64 Version: 1.117 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team <debian-b...@lists.debian.org> Changed-By: Philip Hands <p...@hands.com> Description: di-utils - Miscellaneous utilities for the debian installer (udeb) di-utils-exit-installer - Exit installer (udeb) di-utils-mapdevfs - mapdevfs utility for the debian installer (udeb) di-utils-reboot - Reboot (udeb) di-utils-shell - Execute a shell (udeb) di-utils-terminfo - Terminfo entries needed by newt/slang in debian installer (udeb) Changes: debian-installer-utils (1.117) unstable; urgency=medium . * add checksum verification to fetch-url Checksums-Sha1: 90d5561b54a9ac60e570fdee846712ce33158947 2202 debian-installer-utils_1.117.dsc ad584ecdaa4fefa90182d6196a8a1810cc3b62b7 97300 debian-installer-utils_1.117.tar.xz be949b10ba7baacc79db12adce61a30613bc3607 6100 debian-installer-utils_1.117_amd64.buildinfo a1c893a6db243a8e05496769e37d67cf9420165e 2850 di-utils-exit-installer_1.117_all.udeb 2c6a371c64390443bcc8351f5a11a020bf3a200f 2372 di-utils-mapdevfs_1.117_amd64.udeb 55246ff60e4644b18e71994ccad9b73cfd685427 10110 di-utils-reboot_1.117_all.udeb 7fa592daff3a341a47089f606d4036adf2719578 22344 di-utils-shell_1.117_all.udeb 75fb0f7ee122231105475d45406c77f3fd7b6d3c 2788 di-utils-terminfo_1.117_amd64.udeb 702914d7b9a057360a6fb8a878ac26091fc7b2ae 33864 di-utils_1.117_amd64.udeb Checksums-Sha256: f4941328ef66048d9805cf5d9f57d461eff7ac5e61189043d7f5da69d24d11c4 2202 debian-installer-utils_1.117.dsc 7b4a0340954aa74b518f4593fc543da59f30036eb8dd6401c78329dca0fd52a8 97300 debian-installer-utils_1.117.tar.xz 4d329511e5de23d4015b47cfc3165b6019963ab5ea1b383722e7e1e00c14d0c0 6100 debian-installer-utils_1.117_amd64.buildinfo 5caa8661ba1f3606ae234c7331a61c053d7d0632c7291b7ff765a7f2d51497e4 2850 di-utils-exit-installer_1.117_all.udeb 4fd4eb52bffc76735081276b4d1f9e934e1fd77d360fb4068a7d65ddc6c0191e 2372 di-utils-mapdevfs_1.117_amd64.udeb d057c75f2f7c4a3ba882e8aa00e84e0093542e956ce86d1607c665a327f9fbf5 10110 di-utils-reboot_1.117_all.udeb 4e2d30ab8ee939861b353b2120df57a04f13c2ffc1e960868d8aff4a8787ffe1 22344 di-utils-shell_1.117_all.udeb a02b3339b267de6c7cd29cae922447f1d82d275516da1d0509f03e8d0257c24f 2788 di-utils-terminfo_1.117_amd64.udeb 85a9da5d0af2b5085bd0d373124cdcd997ac1bf9f446e8f8ece9983232145607 33864 di-utils_1.117_amd64.udeb Files: e9d3dcf04e2cd64c00a866b938a47257 2202 debian-installer standard debian-installer-utils_1.117.dsc 2abab0fca09c770e5733bc8ccd6e0202 97300 debian-installer standard debian-installer-utils_1.117.tar.xz 0b078ff6d0c4fec4f25ed80ed60140c6 6100 debian-installer standard debian-installer-utils_1.117_amd64.buildinfo 630267dcf9f25746eca848b2d5b8a016 2850 debian-installer extra di-utils-exit-installer_1.117_all.udeb 063c85f4f5d31e15480313e275d14464 2372 debian-installer standard di-utils-mapdevfs_1.117_amd64.udeb fb424ea0575d3fe7ef0fcf19215f3368 10110 debian-installer standard di-utils-reboot_1.117_all.udeb afed2aec058c70c3f8e56aec04983b7e 22344 debian-installer standard di-utils-shell_1.117_all.udeb 97d8f962521b3f5f2189e756b99f6f35 2788 debian-installer standard di-utils-terminfo_1.117_amd64.udeb 9a6015d850dee0378e9676aa6258584e 33864 debian-installer standard di-utils_1.117_amd64.udeb -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJYNg4hAAoJENBLo6ABJdXA6oUP/237Kyca/8vMsoUrS6ieK6re SWHstuCcgp0lcU8yWQA4WdcWaLaL6OHKBgtFm9Kiydh+DH3olS4D+G66GvSa1Z3l Bt05vhP7OwJeH+f7l1VEVNeQGIvyiPofSbSiUMUSOXXCIVoVn+V8hb4SSwSLu3Nq Myp6lf8zMJvr4K9xrZ8QvcxINqntQochqEdvSO+o3qE9GQvH0L9eqZ8QxhHLfkaT j6OIzB0UMEo7bTPGxF6GqkmUp9R3YXDlhMC28bWXM/DqdVlRC3aqmQ11r5nmA+eq TQa6K2guJUqpqab6k4kdg4ZdiKQGB6p1yeHATK50mCJ82GycW2/hD74dijQynbL3 SrA+z3w/bZEDw1oRfekn47VGWZcyv4sS40Hvg7WJoBqDzWBggUMcep2+vKL697Xj avKvZq6ui6bkQhBihM1zjXQFAGQyFt+YY29c9ucaG76eFYKVkTnP1X5QDHtIa+yw 2ubaby0253jK2IhQyedl+K2PEDfd/aJp3xjnDVZwP6CkJtrLUzNkPLwWvAlXGhhY IyHE07jJsse2enTPELOBSiodzEUDm5uJ8V29nRHZ41QyNO70W+1CktBdufnhKKAz WChCQB4RKBvTR34sW/Xp5/tQow/DEg2yLipFknw0L1QpbowBKsc7pPVP/b+szIbs QHxsFwokwegsFLrSa4i1 =sRiZ -END PGP SIGNATURE-
Re: Lots and lots of tiny node.js packages
Russ Allbery <r...@debian.org> writes: ... >> The web ecosystem is still changing rapidly, with WebAssembly coming >> soon, so probably things are going to look very different for the >> Debian buster development cycle. > > Indeed. > > I do think the Node community takes this too far, with way too many > micropackages that should just be part of the standard library. But, > well, it works for them, and it's not a totally unreasonable way to handle > things. I think Debian should find ways to stay flexible and adjust and > incorporate those sorts of philosophies about the reusable unit of > code. As an interested observer, this flood of packages certainly is a bit surprising (although it is very nice to see the underlying problem of missing build tools being addressed). However, having seen the case of node-os-homedir, it strikes me that there is one very good reason to package things individually. It focuses our disdain where it is deserved. If this were in a combined package, and if the broken code was only spotted after passing NEW, then it would be much more effort to eject it. It would almost certainly be argued, as you'll see here: https://github.com/sindresorhus/os-homedir/issues/4 that the code should never be reached in the real world, so nothing to worry about. That however glosses over the fact that we have downstreams doing many bizarre things, and that someone might manage to reach the hopeless code, and thus suffer foreseeable bugs. As it is, we can just say "no thanks" to that specific package, with the result that the packages that depend upon os-homedir get patched to use something newer (if they're to be packaged), to the benefit of the whole node.js community. On the other hand, I suspect that a lot of this code is really not fit to be packaged yet ... or at least not for stable. Take a look at: https://github.com/sindresorhus/repeating/blob/master/index.js This a trivial bit of code, which will make those of us not in the node.js community boggle, but let's forget about that for a moment. Let's say that it had been packaged in May this year, at version 2.0.1 and that would make it's way into Stretch, and thus be preserved in aspic until the end of the LTS support. In June, version 3.0.0 was released, which reverses the order of the two parameters. I presume that much of the software that uses that function will rapidly switch to the new ordering, and would have thus found our 2.0.1 package worse than useless. This is not really criticism of the 'repeating' library itself, but just an instance where a slight change of timing seems likely to have resulted in poor outcomes, if we let this sort of software into stable. That said, the decision to swap the parameters is apparently justified by the fact that 99% of the usage of this function is to repeat an empty string: https://github.com/sindresorhus/repeating/issues/6 which makes me realise that I really have no clue whatsoever what they think they are doing in the land of node.js 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: Network access during build
Paul Wise <p...@debian.org> writes: > On Thu, Oct 6, 2016 at 11:48 PM, Jérémy Lal wrote: > >> Is there some simple way to check, when using sbuild, that the build >> does not access network ? > > nsntrace could probably be used for this. I think lamby has another > method too. I only stumbled across 'firejail' recently, but it seems possible that one could run the build under it, to lock things down and/or get reports of naughtiness. I've not done more than install it really, but it trivially lets you run commands as though there were no network attached, and looking at the man page it looks like one can set up fine-grained blacklists of things you don't want to happen (so not only networking) and get errors logged if they do. Even is it's not possible to run it on buildds (it's SUID and needs linux >= 3.x), one might be able to use it to detect dodgy unit tests, and segregate them into only running when one can do so under firejail, say. 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: TMPDIR - Do we also need a drive backed TPMDIR ?
Ritesh Raj Sarraf <r...@debian.org> writes: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On Thu, 2016-07-21 at 13:15 +0100, Neil Williams wrote: >> > Now, back to the actual problem. For many applications, we rely on >> > the TMPDIR environments. Tools like Python's modules help use these >> > variables and not worry about the underneath platform. >> > >> > Under Linux, with /tmp more commonly on tmpfs, how are developers >> > dealing with it? tmpfs is limited and multi gigabyte operations may >> > end up filling it all (as is the case in the debdelta bug report >> > above). >> >> As a drive backend, why doesn't swap work for this? There's no mention of >> swap >> in the original bug report. > > Swap will come into effect when the kernel needs more memory. > > As I understand it, TMPDIR on tmpfs is capped, based on the amount of real RAM > the machine has. And any application's view of TMPDIR is based on that capped > size. It's configurable. See TMPFS_SIZE in /etc/defaults/tmpfs And it'll cheerfully use swap, so just make sure you have enough swap for your use case, and set the limit to suit your needs. Alternatively, you can always create a new temporary location where you have enough space (i.e. ~/.tmp/ ) and then either set TMPDIR to that in the relevant user's shell profile/rc or define an alias such as: alias debdiff="TMPDIR=~/.debdiff-scratch-space debdiff" 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: Browserified files and DFSG
Pirate Praveen <prav...@onenetbeyond.org> writes: > On Monday 11 July 2016 01:09 PM, Ben Finney wrote: >> Yet it is built with a tool not in Debian, from a different form of the >> work that upstream actually uses for reading and modifying — the source >> form of the work. So that compiled form is not the source form of the >> work. > > There is a reason for that requirement, it is not like a bible or Quran > or another holy book where we have to follow word by word without > questioning. > > For me, the reason is to be able to modify the code and with readable > javascript file that is possible. > > Yes, to be able to send patches, you will have to change different files > (just rearranged), but is that enough reason to remove the package? > > And why is the people who are so strict about packaging the build tool > not stepping up to package it? FRP for node-grunt was filed in 21 May > 2012 and it is still not complete. So removing these packages until > grunt is packaged makes debian better? They should be in contrib. Allowing them in main removes any incentive to do the work to fix this problem, which I'd imagine is the reason it's not been done. When this was last raised, I looked into it and concluded that grunt is a tangled mess. It strikes me that it might be a more tractable problem if one either aimed to package a cut-down version of grunt, or to write a tool that focuses on the features that are actually needed to do the concatenation in easier cases. That would then allow a distinction to be drawn between the packages that use grunt in a simple manner, and are thus packageable in main, and those that do not. This would make it much more likely that either our tools would then be incrementally enhanced, or upstreams would be persuaded to restrict themselves to a more sane subset of grunt's features. Simply letting them into main removes that pressure, it also means that we're deceiving our users, since they expect buildable source for all packages in main. You seem to think this is a trivial matter, but if there's a bug in one of the underlying (pre-concatenation) source files, the security team then needs to backport the fix to stable. By allowing this sort of thing into main we saddle the security team with the job of hunting down the buggy code in each of these concatenated files, and then attempting to determine whether grunt has done anything subtle in each case. 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
Accepted preseed 1.72 (source all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 26 Jun 2016 16:54:23 +0200 Source: preseed Binary: preseed-common network-preseed file-preseed initrd-preseed env-preseed Architecture: source all Version: 1.72 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team <debian-b...@lists.debian.org> Changed-By: Philip Hands <p...@hands.com> Description: env-preseed - debconf preseeding via environment variables (udeb) file-preseed - load debconf preseed file (udeb) initrd-preseed - load debconf preseed file from /preseed.cfg on the initrd (udeb) network-preseed - download debconf preseed file (udeb) preseed-common - common files for preseeding (udeb) Changes: preseed (1.72) unstable; urgency=medium . * run preseed/early_command after env_preseed, so that one can again specify this on the kernel command line. Checksums-Sha1: 18d47ae76d55ff34c860388c234589601336eff0 1885 preseed_1.72.dsc 7c7bf61a5ca13aceacf07ae7dcadac6212064350 74908 preseed_1.72.tar.xz 7d021389ee193c41c54f2711f8199097465503d1 1836 env-preseed_1.72_all.udeb bd56aa715254665f0f0bc6da3c539cffed6a0482 4148 file-preseed_1.72_all.udeb 15961dda441bb1df7f685475cddc9779675e2c28 868 initrd-preseed_1.72_all.udeb 34baa678833a42f5e744ececcad0e1ce62814689 30806 network-preseed_1.72_all.udeb 054e6cdac06f1158f4666e0c76079dc1b15ac9dc 21618 preseed-common_1.72_all.udeb Checksums-Sha256: a3d792d582d72f88741cbe115543658f2e23c375dce3b43dcd243bb867a2f62d 1885 preseed_1.72.dsc 95588fd527e5c091f2f5e1c2c750b526294a262b3d87c43867e7b582fc114a0d 74908 preseed_1.72.tar.xz d3609b6fc2978aec1e473a890b1da1768c51d5ac1659bbf2e7e65bb8903985d0 1836 env-preseed_1.72_all.udeb 5f34e58735725d075c55c09ca3bbe085919ecbe6083dfbf4975c46f09e58a3ac 4148 file-preseed_1.72_all.udeb ed7c24f236b78af1a2c02467c020611650cc78633cad1c7a516b52cb27cc525f 868 initrd-preseed_1.72_all.udeb a10a2891331ebe7af5371e557f594ab3eb0b356387f152da8228a95bb60a694e 30806 network-preseed_1.72_all.udeb 3336a63ffc3fcc274411ddd2fba1b5ef03197ebafcd0eece05c4e002d012e009 21618 preseed-common_1.72_all.udeb Files: d1e127af41518fa657c90899d2c3cd99 1885 debian-installer optional preseed_1.72.dsc 964f2d6897125c5b5e1931a2e27c76d7 74908 debian-installer optional preseed_1.72.tar.xz 58deb25731c282bc162125f21fc08f3d 1836 debian-installer extra env-preseed_1.72_all.udeb 026463566b886a1d48accda4f5f1b840 4148 debian-installer optional file-preseed_1.72_all.udeb fbe387546bc2a823c43c7ff782fa5929 868 debian-installer extra initrd-preseed_1.72_all.udeb 9ceedff90fe57ec51e2ea54aef6a928a 30806 debian-installer standard network-preseed_1.72_all.udeb 5871c467e90a927f226c96e0fefaf974 21618 debian-installer standard preseed-common_1.72_all.udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJXcMtHAAoJENBLo6ABJdXANfwP/2XVfuj5joe0DdFSC/bNqajc LwOA0zaEwvuX9iSPp0haXdAgDFIRPNrC2DYvzMJg3EA3+GojtIyqv3EyuXw71mV3 XFkwDD5+6ulJgC6Xp34bwyrWSyOjpOR2B/pHL8wmGEYnLrGrrJz5vWit+IipF/eb cMAu1o50P3dHG5RGGcWLMNlTJ1P9u5sPpqfexSx4SXomRyj/yO1KvZcoeDN/f5V3 wFupF3jDkqjeJz7PvPHo8Hn2tm0IRIsjKC/f1Fl63QvF3RSFx/gfBQoMDfRYs/p4 jQBCH3osrAd5sm6M2InrU25uOMf3uu5PQxPeRVlsvFYZ4vwo3M/zktFx0WUMMzYd X7RSquETLRViKNX3JnQwxgBOkchzHFfuNv6RVN/C+3Pug60WznnFy7ZUxNoXhi+d bR+0Ji5f8zMtqKE1fLhLoEUNnFOElLPkEN/ny02I8XhVPKPfm7SwUm8KxKLUbK+m pdPUhG7ATpVflxGIy4aG9GP0J/9/iKy343xEYP59zT5FmHMV0C1U0f/wgHLRoQJ7 mSIYy7djuHaRUdf2ldwraaMF4/WdwWPXbnjKA/w9u3juGbaJ8DTM/IPf9xh/N6aI Aaxowjmm9tlDb6Pu7J07j8Lov38LUNYtiUpOfV/cHVaTyCVtarE07czkXvb2ER1f c6D0Bp8UEJvHDENUhOaa =lp/L -END PGP SIGNATURE-
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
Tollef Fog Heen <tfh...@err.no> writes: > ]] Holger Levsen > >> On Wed, Jun 22, 2016 at 08:13:40AM +, Eliran Mesika wrote: >> > As I wrote earlier, we're open to making certain features available upon >> > request. In the specific case of the feature that was discussed - could you >> > please elaborate what is missing and what functionality is available on the >> > Enterprise edition that you'd like to be made public? We want to better >> > understand the use-case and the requirements to respond to this request. >> >> I'm obviously not Alex but I also object using a software for Debian's >> own infrastructure which is split into a free and an enterprise version. > > Do you also object to DSA using puppet for configuration management? Would objecting make any difference? 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: Bug#815675: ITP: ftpbackup -- Script to backups your data from a Debian system to a ftp space
Arturo Borrero Gonzalez <arturo.borrero.g...@gmail.com> writes: > On 23 February 2016 at 20:52, Jose-Luis Rivas <ghost...@riseup.net> wrote: >> On 23/02/16, 08:37am, Nikolaus Rath wrote: >>> >>> I'm actually rather shocked that a Debian Developer would consider >>> letting this into the archive. Carl, I hope you just filed the ITP >>> before having looked at the program? >>> >> >> He wrote it. >> >> L6: # Copyright © 2013-2016 Carl Chenet <cha...@ohmytux.com> >> > > You are all late, the package seems to be in NEW already [0]. > > I understand that the temptation to package own scripts/pet projects > is strong, I've felt it many times. > > [0] https://ftp-master.debian.org/new/ftpbackup_0.3-1.html Where I notice that it is claimed that: It was downloaded from https://github.com/chaica/twitterwatch which seems wrong to me. 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
