Re: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]
]] Sunil Mohan Adapa > During today's FreedomBox meet, we have discussed that systemd'd > PrivateTmp= is a better solution than libpam-tmpdir for FreedomBox at > least as systemd makes a cleaner mount isolation between processes > instead of managing directories and permissions. > > For this reason, we believe that we can stop using libpam-tmpdir if > most of the daemons on the system use PrivateTmp=yes. For a while now, > FreedomBox has been forcefully adding systemd security features to > daemons that don't enable them. Without upstream blessing, we can only > do this for smaller applications than something like MariaDB/MySQL due > the testing effort needed. They solve completely different problems, though. One handles PAM sessions, the other handles services. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]
]] Daniel Black > How User= systemd directives work with lbpam-tmpdir I'm not sure, > however without a setuid there shouldn't be an invalid TMPDIR env > variable there. systemd doesn't start a new PAM session for services, so there's no interaction there. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Bug#1023778: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]
]] Robie Basak > On Thu, Nov 10, 2022 at 05:37:53PM +0100, Tollef Fog Heen wrote: > > I think it's more wide than that: If you change UID, you need to > > sanitise the environment. Your HOME is likely to be wrong. PATH might > > very well be pointing at directories which are not appropriate for the > > user you're changing the UID to, etc. > > I don't think that this is necessarily obviously the case in general. > For example, I often use "sudo -s" and *don't* want HOME reset. It > depends on the purpose of taking different privileges as to what is > appropriate to reset. I don't think we're disagreeing here. > > I'm not sure this is libpam-tmpdir specific, but rather a bit more > > general: what are the expectations that maintainer scripts can have > > about the environment they're running in, and how do we make those > > expectations hold? This should probably then be documented in policy. > > Agreed, but also, we need a specific answer for TMPDIR. We pass things > into maintainer scripts because we want to change their behaviour (eg. > DEBIAN_FRONTEND). So which specific variables are required to be reset > by maintainer scripts and under what circumstances? In the specific case of changing users, I'd say any that might influence the behaviour of what you're executing, whether it's PATH, TMP, TMPDIR, XDG_DATA_DIRS, PERL5LIB or something else. I can see arguments both for and against dpkg ensuring that maintainer scripts run with a sanitised environment. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]
]] Robie Basak > But are you in essence saying that libpam-tmpdir requires that *every > maintainer script* that runs things as non-root, or starts processes > that do that, unset TMPDIR first? I think it's more wide than that: If you change UID, you need to sanitise the environment. Your HOME is likely to be wrong. PATH might very well be pointing at directories which are not appropriate for the user you're changing the UID to, etc. > I think the answer to this should probably be established by the > libpam-tmpdir maintainer and documented first, for fear of someone else > later coming along and saying that the maintainer script incorrectly > ignores TMPDIR because we started ignoring it to resolve this bug. So I > copied debian-devel@ for comment. I'm not sure this is libpam-tmpdir specific, but rather a bit more general: what are the expectations that maintainer scripts can have about the environment they're running in, and how do we make those expectations hold? This should probably then be documented in policy. Cheers, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Transition proposal: pkg-config to pkgconf
]] "Andrej Shadura" > Most importantly, I need a green light from the current pkg-config > maintainer (Tollef) to proceed with the plan. My interest in pkg-config has waned over the years (and so has the hours put into maintenance of it), so if you want to bring it forward, go ahead. Cheers, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Epoch for node-markdown-it
]] Holger Levsen > On Fri, Aug 19, 2022 at 06:00:44PM +0100, Simon McVittie wrote: > > Epochs cause problems, [...] > > which are? (I agree they are ugly and should often be avoided, but I don't > see any unsolved problems with them, which is why I'm asking.) IIRC, they're not recorded in the file name in the archive, so foo-1.0-1 and foo-1:1.0-1 will have the same file names. This isn't a huge problem in practice since epochs are often the result of an upstream switching from a date-based release model to a semver(-ish) model, such as 2022-03 → 1.2, but in this particular case, it can lead to these problems if/when upstream reaches 22 as their major version number. I'm not sure how snapshot will handle it, as one of the few services that care about this over decades, rather than just the active set of releases. (Or maybe dak just denies you reusing the file name and the uploader gets an error message, I don't know.) Cheers, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: popularity-contest: support for XB-Popcon-Reports: no
]] Bill Allombert > The rationale is that the only info really leaked is the package name, > so it only make sense to hide a package if every system that have it > installed are also hiding it, so it is better to make it a property > of the package than of the system. I think it'd make more sense for this to be an opt-in property of the source of the package, that is, based on which archive it's coming from. (Strawmen: Put a field in Release saying «please send in popcon reports», have popcon enumerate the configured apt sources and check that the version number of installed packages match what exist in those sources, or have a passlist in the «receive report» stage on the server that looks at which distribution is being reported for and validate that those packages (and possibly versions) exist or have existed in the past.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: shim-signed
]] The Wanderer > I can't speak to how big of an advantage A is, but B seems to me to be > pretty important. It's a manual process that includes poking around in MS' partner portal, USB HSMs stored in a safe place and rebooting to Windows, then checking back days (and sometimes weeks) later to download the result. It's not something we would want to do for anything fast-moving. > If that understanding is not correct, I'd be interested to learn what > the actual point of having the shim is. Part of it is also that Microsoft is not going to sign GPL-ed code, certainly not GPLv3. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: shim-signed
]] Hanno 'Rince' Wagner > Hi everbody, > > On Sun, 24 Apr 2022, Tollef Fog Heen wrote: > > > I don't think we have docs for running with a different root of trust > > than MS'. To be honest, I'm not sure we even _should_ have a lot of docs > > around it, since the general brittleness of the boot process, UEFI and > > friends might very well lead to more systems being broken when people > > discover the docs and run with the instructions without understanding > > the implications. > > I am a very firm believer of giving people as much information as > possible while being responsible. Meaning, that I would love to have > that documentation - including a big warning sign which sais "if you > follow this path, you may brick your machine and this is your problem, > not ours". If someone is interested to learn _how_ the security is > done and implemented, why should this be unavailable? Sadly, warnings generally don't work because people will ignore them and break their systems and then blame the people writing the documentation, causing load and grief on people were trying to be helpful by writing the docs. I don't think we should invest a lot into writing the docs required because we can use that effort elsewhere. Documentation requires maintenance, just like everything else and if it's rarely used, we get little value out of that effort. If somebody is very eager to write and maintain that documentation over time, by all means, but we haven't seen anyone step up to do so. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: shim-signed
]] Marc Haber > Excuse me for asking a user question on -devel, but do we have any > docs where someone explains how much a security trade off is > shim-signed relativ to the optimum? I think that using shim-signed is > surely worse than a directly signed kernel, but I don't know whether I > can tell my system (or shim-signed?) to accept MY or Debian's signed > kernel without the Microsoft intermediate signature, and whether this > is any more secure than running an encrypted system without secure > boot at all. > > Do we have docs for that? I don't think we have docs for running with a different root of trust than MS'. To be honest, I'm not sure we even _should_ have a lot of docs around it, since the general brittleness of the boot process, UEFI and friends might very well lead to more systems being broken when people discover the docs and run with the instructions without understanding the implications. As for it being more secure, for that to be a good and meaningful discussion, we have to agree on what the threat model is. What's the threat you want to protect against by using your own or Debian's keys? -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: proposed MBF: packages still using source format 1.0
]] Matthew Vernon > Andrey Rahmatullin writes: > > > On Tue, Mar 15, 2022 at 08:54:50AM +, Matthew Vernon wrote: > >> It's probably unfashionable, but I think debian/patches is not a great > >> way to manage changes, particularly if you're using a VCS for > >> maintaining your packages. As others have pointed out in this thread, > >> doing this means you end up essentially trying to version-control your > >> patches twice - once in the source package, and once in the VCS. > > That's just a consequence of using two different storage formats for your > > packages: a Debian source package and a VCS. As long as both of them are > > widely > > used and incompatible, problems will exist in some form when using both. > > By e.g. merging all patches in the Debian source package into one big diff > > you are just breaking one of these two storage formats for that package, > > essentially mandating the usage of the other one (the VCS) for most of the > > developer operations with it. > > I'm not sure that's entirely true; but even if it were, is that an > entirely unreasonable position for a package maintainer (or team > thereof) to take? My problem with it is that we're then saying that we're not shipping the source (as in, preferred form for modification). This might be ok, but then we should make sure that the «actual» source is available elsewhere, which means it needs to be somewhere we manage, and treat source packages as generated artifacts that can't be turned back into the actual source. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Bug#950426: O: yubikey-server-c -- Yubikey validation server
Package: wnpp Severity: normal Description-en: Yubikey validation server Yubikeys are USB tokens that act like keyboards and generate one-time passwords. The tokens are produced and sold by Yubico . This is a server that checks the validity of those OTP tokens. There are servers written in Java and PHP, while this one is written in C . It implements the server side of the API as described on http://www.yubico.com/developers/api/ and can be used with any client that implements the same API. I no longer use this, and I increasingly think it's a bad idea to write security-sensitive software in C, so I'm going to ask for its removal unless it's adopted by somebody fairly quickly. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: @debian.org mail
]] Jean-Philippe MENGUAL > Forwarding mail from @debian.org to my mailbox makes me apply > complicated filters to stay subscribed to ML I wish. In that case, I suggest you don't subscribe with your debian.org email address. > Do you confirm me it is really not wanted to pull mails from a Debian > machine via POP? I really would love to separat ma Debian box > fromothers. We (debian/DSA) do not provide email hosting. We provide email forwarding. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Do we want to Require or Recommend DH
]] Andreas Tille > Can you give an example for a package that has a non-dh rules file > "working for years" that gives as a result a package with no lintian > warnings without changing this d/rules file? If you're talking about the binary package, fortunes-bofh-excuses. It has some lintian warnings on the source package (primarily because it's not been uploaded for more than ten years) of which only two out of six warnings would be handled automatically by dh. (Yes, also not an important package in the grand scheme of things, and I'm not disagreeing that using dh is a good thing overall. I should probably upload it just to get some of the dust off it.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Please drop anacron from task-desktop
]] Adrian Bunk > Something will break (like in the mlocate case), and people might only > start noticing when they are doing fresh installs of buster after the > release. Which mlocate case is this? -- Tollef Fog Heen, mlocate maintainer UNIX is user friendly, it's just picky about who its friends are
Re: FYI/RFC: early-rng-init-tools
]] Thorsten Glaser > … this was not true for me. Not before init takes over, anyway (as > haveged does not have any initramfs integration), but we’re talking > about “crng init done” here, not “fast init done”. In my scenario, > haveged was started much too late in the boot to be useful (after > tomcat, even). But then, I use a non-parallel sysvinit startup. It’s > fragile anyway; if you install more daemons, for example, it might > also block before reaching the stage where haveged starts on your > parallel systemd setup suddenly. It starts much earlier in a systemd setup; in sysvinit it's in rc2.d, whereas with systemd it just waits for apparmor.service, system-random-seed.service and systemd-tmpfiles-setup.service, so the risk of it being blocked is much smaller. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Unifying logging by default
]] Josh Triplett For the normal and easy cases of line-oriented logs, I think something in the direction of your proposal makes sense, but I think we need to have exceptions for all the weird and wonderful exceptions out there, such as the example below. > - If the software has a well-established set of logfile analyzers > specific to its logfile location and format, and the most commonly > used logfile analyzers do not support reading data from syslog or > journald, the software MAY continue using standalone logfiles (instead > of or in addition to the below behavior) until that changes; > alternatively, such logfile analyzers MAY facilitate the user's > configuration of the software to log to a location they understand. This assumes that syslog is even able to handle the data, both in terms of volume, but also format. Syslog generally deals poorly with binary data, for example. I'm also reluctant to require software such as Varnish to send its logs through any other logging infrastructure, since its logs are rather verbose. I picked a random example from a host and it was ~4kbytes and 97 log entries for the text representation of one request with a backend fetch. Now imagine you're doing a few thousand request-becquerel of that with traditional logging: you'd have about a magnitude more syscalls for logging than you would for the processing itself. This is obviously silly, especially when you can get by with no syscalls at all for it, by logging to an mmap-ed file and using that as a circular buffer. While Varnish is certainly an extreme case, I'd be surprised if it's the only one doing something that doesn't fit into a traditional syslog model. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Use of the Build-Conflicts field
]] Andrey Rahmatullin > If "support" means "allow in the archive" then I think for we support only […] > If "support" means "guarantee that a package will be able to build" then I […] > If "support" means "guarantee that a package will be able to build and I don't think guarantees are particularly interesting here; we generally don't guarantee anything. I think maybe «support» means «are we going to summarily close your bug that you're doing something we don't think is reasonable to do?». Basically something not entirely unlike your option number three, but without the guarantee part. That's an essential point of the reproducible builds effort: if you build the same sources, you should end up with the same binary. A question is how far does that goal stretch? -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Use of the Build-Conflicts field
]] Russ Allbery > Tollef Fog Heen writes: > > > I think we should (over time) aim towards non-reproducible builds being > > release critical bugs, and I think «builds differently in an unclean > > chroot» is a class of non-reproducibleness we need to tackle («fails to > > build» is really just a subset of «builds differently»). > > This feels like a very hard problem if we try to express it through > Build-Conflicts or through careful tuning of upstream build systems. It's > working at cross-purposes with the goal of a lot of upstream build > systems, which try to dynamically discover available optional features and > packages and compile in optional features. Yes it's a hard problem, and as we've seen on this very list in the last few days (with Postfix and icu-config's removal), this autodetection sometimes causes problems. On the flip side, almost all of the packages archive are irrelevant to the build process of any other package, so it should not explode too badly in terms of work. (We also generally solve the problem by compiling in all the options, so that adding another package won't be able to enable any more options, since they're all on already.) […] > To be clear, sometimes there are good reasons for Debian to do the hard > thing and try to solve a problem more deeply than others do. But I'm not > sure this is a good example of that, or a good place to invest significant > resources, particularly since it's in the class of problems that would > require work from every individual package maintainer to carefully > configure their build system to not behave differently in the presence of > unexpected packages. Making it seamless and simple to build inside an > isolated namespace feels like a more productive investment and would > benefit every package. I think it boils down to the question of «Are builds outside of a minimal + build-essential + build-deps» supported?». If they're not, we can just ignore the problem and deprecate the Build-Conflicts field (since it has no use in a minimal build environment). If they are, I think we should move towards the goal of reproducible builds and where we make classes of non-reproducibleness RC-buggy over time. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Use of the Build-Conflicts field
]] Sean Whitton > There are two cases which we think that everyone would agree that there > is a bug, but we are not sure that the bug would be considered to be RC. > We are posting to -devel to see if, in fact, we do have a consensus that > these bugs would be RC, or not. > > (1) a package FTBFSs when: another package that is part of a "reasonable > standard development workstation install" is present, but the first > package does not declare a Build-Conflicts against the second > > (2) a package FTBFSs when: a package that is NOT part of a "reasonable > standard development workstation install" is present, but the first > package does not declare a Build-Conflicts against the second > > Is (1) an RC-severity bug in the package that FTBFSs? Is (2)? I think we should (over time) aim towards non-reproducible builds being release critical bugs, and I think «builds differently in an unclean chroot» is a class of non-reproducibleness we need to tackle («fails to build» is really just a subset of «builds differently»). I'd be inclined to say «yes, it should be RC» and either give exceptions or downgrade that severity if we discover the class of bugs unearthed to be too large to handle. > It is worth noting that in both cases, the fix is highly non-disruptive > to maintainer workflows: you just add the build-conflicts metadata. But > how easy it is to fix the bug does not determine whether or not that bug > is RC. Build-Conflicts should ideally only be used when properly fixing what causes the difference in behaviour to be hard to fix. If it's possible without expending too much effort, one should rather try to fix what causes the problem rather than working around it. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Bug#877900: How to get 24-hour time on en_US.UTF-8 locale now?
]] Simon McVittie > I think this is exactly the "international/culture-neutral English" > locale that you're looking for. I wish we'd get away from this; nothing is ever culture-neutral, and «C» does not give you any guarantees about what language (if any!) the output is in. If people want English output, they should set their locale parameters appropriately. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Accepted pkg-config 0.29-6 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 27 Jan 2019 05:56:33 +0100 Source: pkg-config Binary: pkg-config Architecture: source Version: 0.29-6 Distribution: unstable Urgency: medium Maintainer: Tollef Fog Heen Changed-By: Tollef Fog Heen Description: pkg-config - manage compile and link flags for libraries Closes: 920553 Changes: pkg-config (0.29-6) unstable; urgency=medium . * Add missing "warning" in use in dpkg hook, and corresponding test. Closes: #920553 * Add missing set -e to tests. Checksums-Sha1: 0b16917b49979d5227aecab878e2d75d68789b89 1757 pkg-config_0.29-6.dsc a700a78832ea8f23a7b77a560cf59dcb4c78555c 8145 pkg-config_0.29-6.diff.gz Checksums-Sha256: a5f1a8f976f3d8ad579341ba73514eb3af9dbc6bad8d2b5828699ac24196624f 1757 pkg-config_0.29-6.dsc c06146d878fb7faa4ac3edb5e45188b184cc650a752384d5c1053f41edf590bc 8145 pkg-config_0.29-6.diff.gz Files: f40a3ea1c3cb1b7c514213395740634c 1757 devel optional pkg-config_0.29-6.dsc b70d14960a41816c1440c0921cc266e6 8145 devel optional pkg-config_0.29-6.diff.gz -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEooQRpZYZMXEzGALAtlpIccoZ1xcFAlxNPSIACgkQtlpIccoZ 1xebdw//eTopGSLlH2s1MV2No+u82u5t5fUAFkIJhBSZYnDNhoTJZiWr28lzl7AK xje6e0R5xuOBsbr3yC3LomDT2vPvVq0bNz3PtVaTxIqFW/+f4Ej5WZDo1D3Tr4tN EzP83qQ629LZYJuWVUQ//Rzl3Q8azGOcsL2IoUJHQrapfGrRw1BsDGPLqwvsPOef SQTuWQ7fspGxkeOBX8RFd9iQ5ao9wGu7grgXb6XrorMhFbmxY2up7pdoVeFMv56T cxpeImzbXJdl80t5WEN4OiKnf+1lH9DiXMLbxbNWlGqxWGhGOChwNotJ7e86xWIQ ++JTnmoDPOVSv+9fi7pqBPH+qJD3M80nGxRg8tyULHlHeC5qr2cl+EjZOroUQ89v 5+icAgC3D0Qxh/LdCtU0951S0LSxdXllePk7/bFDiKkf20lN5lAbMfiLqrz4rJ2d /md6c+oPvBObSLBRvS2A9KsGYxJbc5tiJ8brHz05oXT/zNP7MfZqtLfHa44Qyek3 zM/Xe+4LJHNcPbaD+XyPDH6ZwTOR2cZAWv7u0iIdPLNd7nLr45zIEC6PEtgowMDV BpX1NmxRrxs0I4H41n9e7u5ZLpsaNLqxBCqxwcSFcmmtake1KW2bMFw3T60BygeN cYLjQT4WrnJOqYvXy7H5txURyQgqATZTvvlAsM1mEeLPNMRSYf0= =FWYX -END PGP SIGNATURE-
Accepted pkg-config 0.29-5 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 24 Jan 2019 10:01:45 +0100 Source: pkg-config Binary: pkg-config Architecture: source Version: 0.29-5 Distribution: unstable Urgency: medium Maintainer: Tollef Fog Heen Changed-By: Tollef Fog Heen Description: pkg-config - manage compile and link flags for libraries Closes: 848706 916772 Changes: pkg-config (0.29-5) unstable; urgency=medium . * Add dpkg-dev to Suggests and make pkg-config-crosswrapper error if dpkg-dev is not installed. Add corresponding autopkgtest. Closes: #916772 * Ignore unknown architectures when setting up symlinks. Thanks to Jim Patterson for the patch. Closes: #848706 * Bump debhelper compat version to 10. * Add Rules-requires-root: no to control file. Checksums-Sha1: 08d363f1730f1a2b97fa6fa3cae769d17005f7c4 1757 pkg-config_0.29-5.dsc 3a02d89eaf6d7c2f8bc00956b1c2318ede685be8 7989 pkg-config_0.29-5.diff.gz Checksums-Sha256: 9064189e13a45250a2d977101af31af5596e25adcd9614a2d3ab10143189d8f8 1757 pkg-config_0.29-5.dsc 99b4570a2a1d0fc0ad7f3e650ee0de4243f8ecf38b4860b7c02a1ff06dec0fb7 7989 pkg-config_0.29-5.diff.gz Files: 2619e3f0c18b137910be9d6bd4cd09d9 1757 devel optional pkg-config_0.29-5.dsc d4d0d2114c9cf75fd15bb3c1cbd87452 7989 devel optional pkg-config_0.29-5.diff.gz -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEooQRpZYZMXEzGALAtlpIccoZ1xcFAlxLaWsACgkQtlpIccoZ 1xeT8RAAxBN/606Nu9RbsNe/B+3rJERYw6X2d5pFbs/E1NXTFV9proHHm4m0Ku+k C/Yx/Tnmiid4kBaNlcoUBkISaHxYFMQ0brwtCqJutvnGGJ7xjo/TZzGR8MrzFQgN mkIzChgnhvKMc9povtSEPpbChMvf54FpWQAMyclwi0BW0hY/1Jd1bv6Dsi5A3E2j YwWXXguKK73Km2sqC/gNT7eR2roqFJdjs0XXOEgigKRar9zGdZ+++PZ9Sh+LluQF 0R/Yk5JWlet2ZV3FGK8W+NOexgOHqhZAMV7a7+Nh2gyxnWtzb2k51qLyq9vXcSXy NZH3M1XjSm0JjNTV/tyRjtoyy7hdKfSqj6bR0GuYGZLankaAYyqmy58gwc9IDZZV RPiX3RVw2eKmdQKNpRdrfHEQfTACtJTN3ExKrbFuU/KRYvcTcSoIrwUaIall9MWH YG1hWdSXrxVraPIJgzOZpwPMFIZUDAT4ouNWCw2yboWTqbnWpWENoxJYVw3GnnRd ymmrHdJpa8bhPZHQlVojXHMd6KvOZBdElFIuaWbD5BLCvVLuKjtmWM3bs7UcSoZ/ IzckQz2QzOdqU6cigt3Ws7ijcszxyXpkMmCaZXH/rRpf0jgQlnAkXNKkZ1jwMa+f ZC9FgIHZ7dNHy5MEacxAFTwhN9khpt4gdC9mq9FTKbybQ7uqsVc= =g9ZB -END PGP SIGNATURE-
Re: Bug#915407: libpam-systemd: please add a virtual package "logind" to allow alternatives
]] Felipe Sateler Two minor typos. > The proposed virtual packages are: > > logind: a org.freedesktop.login1 D-Bus API implementation «an org…» > default-logind: should be provided by the distributions default logind > provider (currently pam-systemd) distribution's. Otherwise, this looks like a good idea to me. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Sending using my @debian.org in gmail
]] Alexandre Viau > It is true that others are vulnerable, but this is a choice that Debian > makes and it can be fixed. If we wanted, we could largely limit this > with more restrictive debian.org DNS records. I would say «changed» rather than fixed, since I don't think the current setup is wrong. One problem with providing outbound SMTP service is that we'd end up with a bunch of user support requests when inevitably something didn't work. DSA already has enough work to do that we'd rather not have that extra load. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: wicd-daemon-run_1.0_amd64.changes REJECTED
]] Dmitry Bogatov
> which is provided by `-run' package:
>
> $ dpkg -L wicd-daemon-run
> [...]
> /etc/sv/wicd-daemon/log
> /etc/sv/wicd-daemon/log/run
> /etc/sv/wicd-daemon/run
> /var/log/runit/wicd-daemon
Does it also provide an init script? Else, it's RC buggy according to
9.11 in Policy.
> #!/bin/sh -eu
> exec /usr/sbin/wicd --keep-connection --no-stdout --no-stderr
> --no-daemon
>
> Note `--no-daemon' option. Logging is expected to go on stdout, which is
> piped to script in `/etc/sv/wicd-daemon/log/run', looking, usually like
> this:
How do you ensure that those settings are kept in sync with any command
line flag changes the maintainer makes in their package?
> 1. Provide runscript by {foo}.
>
> It is infeasible due two reasons:
>
> 1.1 Technical. Most -run packages provide dedicated system user to run
> logging process. It would introduce cruft on systems
> of users, that install {foo}, but do not use Runit.
I don't think a small number of log users would be a particularly high
cost to bear. You could also create those using triggers when runit is
installed.
[...]
> 1.2 Social. Maintainer of {foo} can rightfully refuse to maintain
> support for `runit', not mandated by Policy
I think
https://lists.debian.org/debian-devel-announce/2014/08/msg1.html
should be sufficient here:
For the record, the TC expects maintainers to continue to support the
multiple available init systems in Debian. That includes merging
reasonable contributions, and not reverting existing support without
a compelling reason.
Cheers,
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Re: Upcoming Qt switch to OpenGL ES on arm64
]] Adam Borowski > Tested on an early bronze age i386 box with an "82915G/GV/910GL"; both > glxgears and es2gears_x11 work fine. I don't think anyone is going to run a > modern desktop environment on a machine older than that. > > But that's an Intel card -- with nVidia, stuff 3 years old gets dropped from > the official drivers while 2 years old doesn't get Linux support yet -- and > nouveau has problems on its own. es2gears_x11 works fine on my GF116 board (release date: 2011-03-15) using the proprietary drivers (on an otherwise testing system). -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Accepted mlocate 0.26-3 (amd64 source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 14 Nov 2018 20:04:27 +0100 Source: mlocate Binary: mlocate Architecture: amd64 source Version: 0.26-3 Distribution: unstable Urgency: medium Maintainer: Tollef Fog Heen Changed-By: Tollef Fog Heen Closes: 602485 770699 867640 904050 907579 911653 Description: mlocate- quickly find files on the filesystem based on their name Changes: mlocate (0.26-3) unstable; urgency=medium . * Update list of excluded file systems. Closes: #907579 * Run cron script under nice. Closes: #602485 * Suggest nocache. Closes: #911653 * Update upstream home page location and watch file. Also update debian/copyright. Closes: #867640 * Use getent group instead of sg in postinst for testing if the mlocate group exists or not. Closes: #904050 * Pull in patch from upstream to fix up include guards for db.h and ship the file. Closes: #770699 * Update VCS-git fields. Checksums-Sha1: 159e4a8710c861a52055ca25a5e5c1333aebe415 1892 mlocate_0.26-3.dsc e6a3bf302fa65a8652c5573f43800935f1d01cba 7761 mlocate_0.26-3.diff.gz 9a629cc724b5dfaf0b9628f4d67eddc38323d7af 105648 mlocate-dbgsym_0.26-3_amd64.deb f6809bc00ba3447a04a8deff8a8e116a77356b9a 5427 mlocate_0.26-3_amd64.buildinfo 9984d533f2ff090c85b7cb2fb5e212565fb641fd 97668 mlocate_0.26-3_amd64.deb Checksums-Sha256: 80e819e62cd8883027528d9abc7b6d62584714dee9f65c3065ae4fe52655f18a 1892 mlocate_0.26-3.dsc bc9092da179bd81874f86738d25d91a6d10ae05c8a21505f73e42c46efb0f14c 7761 mlocate_0.26-3.diff.gz deddc1249168c8773fbd31b5f5d40651944d4d1bfd1fe8282eac66fa23d661b1 105648 mlocate-dbgsym_0.26-3_amd64.deb 2a3e220a526eb69618590122b6ad76c85da8518275f1024d1e0ca471e155a4cd 5427 mlocate_0.26-3_amd64.buildinfo fee215b59be0bb278c600ec8e6735b1be30842b5736f2e6f0585598c283b2413 97668 mlocate_0.26-3_amd64.deb Files: 21de0aabd814c82dabf6f7e7c212ec15 1892 utils standard mlocate_0.26-3.dsc 1c12d09901365d16a8578e92f27a4e19 7761 utils standard mlocate_0.26-3.diff.gz 70935b00e60c0d46bae2366e1ab54d7d 105648 debug optional mlocate-dbgsym_0.26-3_amd64.deb 0b8fb85242b4ef987c7b0a0b2ede5074 5427 utils standard mlocate_0.26-3_amd64.buildinfo 74e1c45950e010081b89201c1197f2b3 97668 utils standard mlocate_0.26-3_amd64.deb -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEooQRpZYZMXEzGALAtlpIccoZ1xcFAlvsjB4ACgkQtlpIccoZ 1xeN3g//da5YklKz+V1LCNwtt/DPFyY3RIwk94UAGq/8p7WHqonFQ4yyyj7YuPmW doef9nsdna43+sUHK5G6uuYCsj5HB5eRYssfwHhtYHJuYi9kJLmgI36ZSEl+fJxF 2vPd93toXWYFXaazgI+ayZz6jugbrurTpYSSRaqTN6GnaHRG1iQKEICYwfGogLXx OK2ta+aYvjlo/i4483OluZBXGwdjsCq0yJTV+lLrmzAw+YCKD5uKKiBMSrYvxMTP bHUxNNP4neORCHkWpSFyVRLKYhbV6hIM2ld2avx+TVNVF9UGG0T7W5kNjqG9OUUF 3mHuqEyY3xThAa0kUgXKnXF+8jeRKRsbY045AEbisGL2MbiN75BIpbE38TO+FX2X aN9Ljs6X00AIXn03Jo8McESGMLZouxy8wvAk26+0s+0oIxga26vPVll/JU/PqxHB UNbYu2793PliiUbMGJQOD35ZNOGoxf9y7Y0Uft6lvrP1Ls1zSFsHK4LirQQ+wosI 3ntD6GcjYHMZzGFyJWJE4sDBIOphLSOwkvaog7Ho3VsLsa6gcgQXLCADEjf16bxS gFNhrLvwWJW23UY+XeWzXZpNC3EXj64C9xm/EeTgy6gUUxIcHeoiLP7+FnVO73G/ TmABhjD3kcwydTbRTJ2Wa4Nr5zpD6Oj80fxSyPNlTR/eBGCLwJE= =XqaD -END PGP SIGNATURE-
Re: I resigned in 2004
]] Vincent Bernat > ❦ 11 novembre 2018 19:20 +0100, Wouter Verhelst : > > > Meanwhile, it makes sense to be courteous to people who were a DD once > > but really couldn't care less now and want to get rid of the nagging, > > which seems like a far more likely scenario. > > Then, they should click on the button they are asked to click. This > takes far less time than a long (and discourteous) rant. It asks people to click a link if they want to retire, something which is not the right course of action if they already have retired or rather, left the project. The mail also gives the impression that we'll just delete their account if they don't respond, so maybe it should mention that we will send out a ping on debian-private? (I also wonder if we should just require people to opt in to their DD-ship on a yearly basis instead of doing most of the WAT/MIA dance. If people can't be bothered to reply to a single email saying «yup, another year please» with some reasonable amount of pinging and time to reply, they are effectively MIA, at least if they haven't let people know on -private or similar.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Confusing our users - who is supporting LTS?
]] Michael Stone > On Tue, Oct 23, 2018 at 10:05:35PM +0200, Tollef Fog Heen wrote: > >We should not be in the business of distributing known-vulnerable > >software. There are practical considerations around point releases and > >such which makes this not-really-true for a period of time after there's > >a security update out, but this gets converged at each point release. If > >you look cdimage.d.o, we are only distributing the latest point release. > >I think the same standard should apply to cloud images. > > It does; they are distributing the latest (lastest) point release. Noah writes that the latest image is 8.7. The latest jessie version is 8.11 according to https://wiki.debian.org/DebianJessie. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Confusing our users - who is supporting LTS?
]] Noah Meyerhans > To be clear, the ongoing cost to the cloud team of dealing with jessie > on AWS (where this issue originally came up) has been exactly zero, > afaict. That is, we haven't actually updated anything in >18 months. > Users who launch a jessie image there get 8.7, with 106 pending updates. > As long as LTS exists and users are happy with it, there's nothing > strictly wrong with this situation. They should update their instances > and reboot, but from there, they are free to continue using them in > relative safety. I disagree with the statement that there's nothing wrong with this. We should not be in the business of distributing known-vulnerable software. There are practical considerations around point releases and such which makes this not-really-true for a period of time after there's a security update out, but this gets converged at each point release. If you look cdimage.d.o, we are only distributing the latest point release. I think the same standard should apply to cloud images. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: no{thing} build profiles
]] Jonathan Dowland > On Tue, Oct 23, 2018 at 02:11:48PM +0200, Marco d'Itri wrote: > >PGP-signed mail is an highly advanced feature, so I do not think that it > >is unreasonable to expect from users who want to use it to also install > >gnupg. > … > >No: it is also TOTALLY POINTLESS to even just automatically verify > >received emails because any result is meaningless unless the local user > >has manually configured local sources of trust. Which requires > >installing AND configuring gnupg, so again the user has to know about > >it. > > I have sympathy with that position, but in which case PGP should be > disabled by default in the /etc/Muttrc files too. Wouldn't it make more sense for mutt to just go «oh, no GPG installed, let's note that there are signatures here, but they can't be verified, since there's no GPG installed on the system» and let the user know that? No need to actually disable PGP support. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: no{thing} build profiles
]] Ivan Shmakov > >>>>> Sune Vuorela writes: > >>>>> On 2018-10-21, Jonas Smedegaard wrote: > >>>>> Tollef Fog Heen writes: > > [I see I’ve managed to botch References: for the > news:linux.debian.devel readers; my apologies for that.] > > >>> tinysshd only ships a systemd unit file; neomutt links against > >>> libgpgme11 which again Depends on gnupg. It’s the kind of > >>> dependencies that individually make sense, > > I beg to differ; I suppose (though haven’t actually tried) I > can start tinysshd straight from rc.local just as well, or even > write my own init.d script, right? Having the dependency in > place just makes it harder to me to contribute an init.d script > for the package. It actually doesn't, because installing systemd by itself does not change the init system. (As in, the dependency is wrong, and if it wants to declare «only useful with systemd as init», it should depend on systemd-sysv, not systemd.) (Also the bits downthread wrt Depends/Recommends.) > >> I disagree that libgpgme11 should depend/recommend/suggest gnupg > >> at all: As a library it cannot possibly declare how tight a > >> relationship to declare - instead, all _consumers_ of the library > >> must declare whether they depend/recommend/suggest gnupg. > > I suppose I can agree with that. AFAICR, the libgpgme11 > maintainer was concerned that some of the users of the library > may break if gnupg is not available. (Investigating that is > still in my to-do list. Don’t hold your breath, however.) Having some bits of a package not functional if Recommends is not satisfied is fine, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=119517 for a TC ruling on it. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: no{thing} build profiles
]] Ivan Shmakov > (BTW, while we're at it, could someone please explain me what > tinysshd [1] does need systemd for? Or why installing neomutt > has to invite gnupg along?) tinysshd only ships a systemd unit file; neomutt links against libgpgme11 which again Depends on gnupg. It's the kind of dependencies that individually make sense, but where libgpgme11 should probably have a Recommends: gnupg, not Depends. This is pretty easy to find out by using apt-file show $package and apt-cache show $package, btw. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: dpkg path-exclude
]] Anthony DeRobertis > This works at least as far back as Wheezy. IIRC, I wrote the patches for this in the hacklab (aka the decommissioned church) at Debconf 7 in Edinburgh. Guillem wrote code based on that, which was merged mid-2010. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Bug#903815: ITP: pw -- A simple command-line password manager
]] Michael Stone > On Mon, Jul 16, 2018 at 03:14:20PM +0200, Dashamir Hoxha wrote: > >It writes to `/dev/shm` which is not disk. > > All else that's been said aside, this idea is also dangerously > incorrect in a typical configuration: the tmpfs backend will write to > swap under memory pressure. (This is also true of the memory used by > the process; if it's actually important to keep data from being > written to persistent storage, it should be set unswappable using > mlock. I have no idea how one would do this effectively in a shell > script.) Assuming it's small enough, using a pipe (or possibly a FIFO) could work. That's kernel memory and iirc it won't be swapped out. (I'm happy to be corrected on this, I'm basing it on what I've heard before and my recollection of it.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Accepted sash 3.8-5 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 09 Jun 2018 22:33:23 +0200 Source: sash Binary: sash Architecture: source Version: 3.8-5 Distribution: unstable Urgency: medium Maintainer: Tollef Fog Heen Changed-By: Tollef Fog Heen Description: sash - Stand-alone shell Closes: 869137 872356 874282 883111 898293 Changes: sash (3.8-5) unstable; urgency=medium . * Add German, French, Dutch, Russian and Portuguese Debconf translations. Closes: #869137, #872356, #874282, #883111, #898293 Checksums-Sha1: 05c59eef41f1b9a545d6417082f358002bf95910 1770 sash_3.8-5.dsc c36eb4e0c48932e7a837f6c6b5d06eac2fe7d58f 18096 sash_3.8-5.debian.tar.xz Checksums-Sha256: a5eb8ce723ceff052529365412494fd476f1bf69942d597796c09916dde7b63a 1770 sash_3.8-5.dsc 019fa44edfdb4b8aeece804dc08e5ece92ce886b02b61630cbfdd93c9d1c33ab 18096 sash_3.8-5.debian.tar.xz Files: 4d1ae9cbf6df2ce826692884a3632d36 1770 shells optional sash_3.8-5.dsc a6e9bda46e0bfdcccb171f64cbc676e6 18096 shells optional sash_3.8-5.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEooQRpZYZMXEzGALAtlpIccoZ1xcFAlscOoAACgkQtlpIccoZ 1xcx2g//VFETJsktjglrBiMa1+s7FAcynpMvY51YSrBQ1QJaqheADPqFMH9+Zpts 21MBz4PGKx2v81Qz3xhddJWAcW1GAlDpWg5Da7zwDzOtISdSFOPBcOXPfP557Nw3 brAYCfeXJ4Biv0deXejcMmVcRRNOxI3gSrnKyS9V5OnQZBoUuCRlEDzX/qn0Sfok 3PHtyy1vaP9/8VliCpsYEdw/3wJTycP1K10TPQRXFasXNXirJPCs4pd5FAMwTJdV hxYDEqRx097fHzxXxDsGjjpVGjfaL0WayhAFJeydDoAifVjHWqjUviesi8AImuni wG66c53cgI0nn4AYjo5zRjWHgoGOXRuPSFDqLOZUe4AUj72kkMRg9guTqLBNY3x4 La+cJr+GvELZaEJfxYaP7p0WcLmq59sDzT8skbPC804QmuF6HXnMO2CdEvsTTPBt Df5YMMuZEFlZrCjaUZi+Fy50U0bNoksRtYwuFot3MemEu4hqN5/7jEPycqTpwcN/ 7FS65Gn7R087Vm3X+oZfmN3+PiGahk6xxHrNi2QQIbNlHkUkT9znb9W39Teuhgl/ r8t1hmwTn5PMILHhMGC2/YAd1J4gM10wztx1Q06UuPQE6HLzGgOMPRWkJemRjj0Y p7TfVumL8fwhAnFpxvXySBIVR8IfYj0zodRH3bCnU1AdOlnPICY= =fjBe -END PGP SIGNATURE-
Re: concerns about Salsa
]] Russell Stuart > On Thu, 2018-06-07 at 18:14 +0200, Tollef Fog Heen wrote: > > Packages does not imply automation (lots of people maintain machines > > by logging into each one and running apt by hand and $EDITOR on their > > configuration files; I suspect this applies to the majority of > > desktops and laptops by people on this list), and git repositories do > > not imply not-automation. Those are simply transport mechanisms for > > bits and the level of automation you use is not decided by git-vs- > > packages. > > No, distros are not "just transport mechanisms". We are not disagreeing here; I was talking about packages vs git checkouts of services, not about distributions. > I'll drive the point home with yesterdays (literally yesterdays) > headline: "Three months later, a mass exploit of powerful Web servers > continues". The headline is referring to the 1000's of unpatched > Drupal servers out there, unpatched because patching required upgrading > to the latest version which is too hard. Wordpress sites using the > Debian package with unattended upgrades installed would likely have > been patched before news of the exploit made the headlines. Yes, this happens. I've also come across installations of Debian several releases out of date where everything came from packages, so using packages is not a panacea. Systems have to be maintained no matter where the bits on the system come from. [...] > I accept that's doesn't leave the Salsa team with much choice, but it > still leaves me scratching my head. Containers / VPS's / VM have been > a thing for years now. They solve this separation problem in a way > that reduces the workload for everyone. At the risk of extrapolating from a single data point, I think Alioth showed that using VMs does not fix this automatically. (I'm not picking on the Alioth maintainers, I used to be one of them. The job of maintaining your own separate infrastructure has a non-trivial cost.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Accepted norwegian 2.2-4 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 07 Jun 2018 21:43:54 +0200 Source: norwegian Binary: inorwegian wnorwegian aspell-no myspell-nb myspell-nn Architecture: source Version: 2.2-4 Distribution: unstable Urgency: medium Maintainer: Tollef Fog Heen Changed-By: Tollef Fog Heen Description: aspell-no - Norwegian dictionary for aspell inorwegian - Norwegian dictionary for ispell myspell-nb - Norwegian Bokmål dictionary for myspell myspell-nn - Norwegian Nynorsk dictionary for myspell wnorwegian - Norwegian word list Closes: 900290 Changes: norwegian (2.2-4) unstable; urgency=medium . * Fix invocation of dh_auto_build to properly pass the right args. Thanks to Chris Lamb for the patch. Closes: #900290 * Bump debhelper compat to 11. * Ship nb.cwl and nn.cwl files to make aspell/aspell-autobuildhash happier. Checksums-Sha1: d493e7d045d88d44f5fef203940a7eae6566e285 2087 norwegian_2.2-4.dsc 59fcf41a9d54b62568febc5ef549b40597f84209 17443 norwegian_2.2-4.diff.gz Checksums-Sha256: 63ab634fee3092f057b13ae7b79e6e3c479303cb47dc0a48f0f24ab7f8506604 2087 norwegian_2.2-4.dsc df534d9e16284e9b524458a72e882768f824f10c77041b89400d44bf4d5b5b6b 17443 norwegian_2.2-4.diff.gz Files: 13d5819f940edb0c6b1a5ccefef5158d 2087 text optional norwegian_2.2-4.dsc 60a2fcb08373b90767bf05f9a7508918 17443 text optional norwegian_2.2-4.diff.gz -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEooQRpZYZMXEzGALAtlpIccoZ1xcFAlsZjNgACgkQtlpIccoZ 1xcHDA/+Lomj+KUk8LUU1aTmlXfXBdytlPU5R7AAIcrn9ddd42qq8Bxd3/16XzzC p7d0xZiOgjifcQ/k2whJ1x/ZfOaoCl5Gq88D6prW2jt7MI0s9r/6a6ssQg7cL1N/ gQq2uw7h+qcXZ0IRWcJOdbWLAqiZ1GJU1yMWKo+Yfj3Yz7Uv2RWdmRWbFyFO3JeU P+AW/kw3mpwc8a9GuLwff4GyciTwCFQv/CsBIialxBsSG9Ti5/G6XgKpve5QQCSN NE+c/Njd/9Vd5j15/gfAEpyQvhA1t5tblbRYAGddQz6AAPHDU5CuVo3CnVFROOfS tdMd4HG0kHXNJDcCTnvnISKawQatGAKCzx8fxXzFsipvJJLO8o4u6MaSx2LHPOby +zd38fjg6RMLdWhibjvdVSIQDDPZsiUjZ4ZMIqmv63XNEYw+pCSDsFh1lhmU2iav buFlTMdf94ZBV4Ooxi3vwnSAyFniZkiAD32lj+ZaNltCLW2L3wvHbY9snXVH1iDA w8qWSDXd3t3Ep9eFDDdt73+H0tj19TGKRhXtSAvbn3M74NUjXPYGV8JwDvt1JraW u2GAodqGYAPeqZkQg9MbzYmZTivutXIAsFhA56YUcUXmkVWa7cy23CLVt5/+EcF9 6JeAubPioVS5tr9oIfIGgSIDEKfvptdNNWNVAudQ0NwHVs4+I/E= =l1Ew -END PGP SIGNATURE-
Re: concerns about Salsa
]] Russ Allbery I agree with the points in your mail, but I wanted to expand slightly on where I think Debian stands in the scale you described. > I think people's varying reactions on this thread may have a lot to do > with where they are in this hierarchy of scale, and what problems they > therefore anticipate. But the Debian Project infrastructure itself seems > to me to be firmly in that middle tier where it makes sense to run the > core thing out of Git and the supporting scaffolding from packages. We > have a lot of things that we're working on directly and intensely as the > core mission of that part of the project, but generally they're deployed > on one or two machines and don't need management at scale, canarying, and > rollback properties. As DSA, I'd love to have Kubernetes or similar in stable so we could have deployment using containers and just rebuild those and then service owners could have a good way to do both development, testing and deployment of their services. It would also offer a much better way for people to help out with services: If you want to help with, say, packages.d.o, you can download the git repo and some sample data (or database schema + importer), build a container with your changes and then test them. This is significantly easier than the current way, which is something like: install a set of packages (defined in the debian metapackages repo), then maybe set up some scaffolding (defined in dsa-puppet), then deploy the service (with scripts that make assumptions about the environment, host names, etc; if you're unlucky that «script» is only in the service owner's .$SHELL_history file), then test that and finally provide a patch with just the relevant changes for the feature or bug you're trying to implement or fix. So while we're not likely to have many deployments of each service, lowering the bar for setting up services, defining a very clear boundary between the service and its surroundings and making service development much easier would be worth it for us. > More broadly, one useful way to think about the mission of a Linux > distribution is to make all the things our users *don't* care about > effortless and simple, so that they can invest all of their energy and > attention into the one or two things they *do* care about. Trying to get > them to package those few things that they care about deeply is more > dubious and often doesn't add much value for them. This is a good point. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: concerns about Salsa
]] Russell Stuart > On Tue, 2018-06-05 at 15:44 +0100, Ian Jackson wrote: > > Packages are great for software which you can just install and use > > without much fuss. That is often true for mature software. But for > > services which are less mature, and more complex, and which have more > > tentacles, the admin is likely to need to change things. This makes > > using packages awkward. > > I think it's better to express the trade off in terms of consequences. > > - Using software packaged by a distro requires very little effort, > which makes packaged software the ultimate sysadmin force > multiplier. I know sysadmin's who exploit it to the extent they > maintain literally 1000's of working boxes. > > - Taking a package straight from the developer gives you flexibility > using software packaged simply can't provide or worse you can't use > it at all because it's not packaged. The downside is you become a > nurse maid for the box it's installed on. Nurse maid's are literally > orders of magnitude less productive than one sysadmin maintaining an > automated assembly line, so the end product had better be orders of > magnitude more useful than the packaged version. Packages does not imply automation (lots of people maintain machines by logging into each one and running apt by hand and $EDITOR on their configuration files; I suspect this applies to the majority of desktops and laptops by people on this list), and git repositories do not imply not-automation. Those are simply transport mechanisms for bits and the level of automation you use is not decided by git-vs-packages. For debian.org hosts, the choice is primarily a matter of privilege separation: Service owners generally don't have root on the hosts, and so if they are to be able to update the service configuration, the service must run as a user they have access to or we need to build control planes with access controls which allow service owners to control their service. DSA has root on the hosts and maintain those, but we don't run all our services, so we'd rather not be on the critical path for updating various services (which we'd need to be if those came from packages). -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Kanboard and alternatives for mentoring
]] Daniel Pocock > Even if DSA didn't grant access to the instance you run now, would it be > considered easier for you to support extra, identical instances of RT > rather than supporting Kanboard or alternatives? That depends on what the alternatives are, but I think that's unlikely. We'd like somebody else to run the service since we already have plenty enough to do and there's no real reason for it to be something that needs to be provided by DSA. Cheers, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Kanboard and alternatives for mentoring
]] Daniel Pocock > Another possibility: DSA already run RT and there is a Kanban > extension[3] for it. I doubt we're interested in making the RT setup generally available for people to create and sign up for queues and such. (Speaking with a DSA hat, but not for all of DSA as we have yet to discuss it.) Cheers, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: What can Debian do to provide complex applications to its users?
]] Russ Allbery > Paul Wise <p...@debian.org> writes: > > > I think the discussion we are having here is orthogonal to > > containers/flatpaks. > > > If Debian were to have a repository of containers/flatpaks, then it > > should meet Debian standards. We cannot just say "here are some > > containers, completely unsupported and might not up to our standards". > > To achieve that, I think it would be best to automatically convert it > > from Debian binary packages. Also, since we are already doing packaging > > work, it makes sense to base any container efforts on that, just like > > our cloud efforts have been. > > I agree with this. > > Putting aside completely missing licenses or completely missing source > code (these are sometimes more fixable problems, since those are > considered suspect practices even in the upstream communities), the root > problem here is vendored dependencies. Most modern languages, not just > Java and Node, are switching to vendored dependencies with some mechanism > for freezing the dependencies for a project. See Rust, Go, and > increasingly, Python and Ruby, and I would expect to see the same for any > new, popular programming language. I think there's at least two types of vendoring you're referring to here, and they're substantially different. One is how Go currently does (but my understanding is that this is changing in newer versions). Here, the source code of dependencies are shipped together with the source code for the application. This leads to trees like https://github.com/kubernetes/kubernetes/tree/master/vendor where any one of those dependencies might be a released version or tag, or it might just be a random git snapshot, and there's not really any way to know. The other (you refer to this as freezing dependencies) is how Node.js/npm/yarn, Ruby/gem, (to some extent) Python/pip, and Rust/cargo does it. In those cases, you have some file specifying the versions of libraries the application needs, usually as «this version of this gem/crate/package» and there is somewhere those packages live by default. Quite often, there's also a lock file of some sort which lists out the exact versions used, recursively, which ensures you can deploy the exact same code multiple times. The second method means you can reason about what versions of code are included where. You might still have to patch five versions of libvulnerable, but at least it's possible to find which five versions are in use, and get those fixed in a central place and then rebuild everything that's vulnerable, recursively. Not the most fun job in the world, but it's at least possible to automate somewhat. I'm curious what, if anything, we can do to better support the second model. In particular because (as you note) it's very much in vogue with lots of upstreams those days. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: udftools, pktsetup and init scripts
]] Ian Jackson
There is still no need to Cc folks on Debian lists unless explicitly
requested.
> Tollef Fog Heen writes ("Re: udftools, pktsetup and init scripts"):
> >] Pali Rohár
> >
> > > What do you think about moving pktsetup into own binary package? Users
> > > who do not need packet writing configuration and only need tools for UDF
> > > filesystem would install only udftools package.
> >
> > udftools is a tiny package, splitting it seems a bit meaningless.
>
> AIUI the point of splitting it would be to allow people to avoid the
> udev rule. It is often a good idea to separate packages containing
> quiescent utilities from packages containing automatical-launching
> configuration etc.
There doesn't seem to be anybody asking for that in any of the open
bugs, AFAICS. It's trivial to mask a udev rule if you don't want it as
well, so while it's sometimes reasonable to do what was suggested, it's
not a given.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Re: Bug#886526: ITP: rt4-extension-commandbymail -- Change metadata of ticket via email (Request Tracker)
]] Andrew Ruthven > The intial packaging work has been carried but by myself for my employer. > Ongoing maintenance will be by the Debian Request Tracker Group (of which > I'm a member). This is already packaged as librt-extension-commandbymail-perl, but feel free to have the team take it over. (I'm the maintainer.) Cheers, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Why do we list individual copyright holders?
]] Markus Koschany > Am 02.01.2018 um 19:38 schrieb Russ Allbery: > [...] > > I think of the Standards-Version header in a package is a bookmark: this > > is where I last left off in updating the packaging. It doesn't change the > > standard by which the package should be judged. > > I believe that the Standards-Version header should not be part of a > debian/control file. I understand your reasoning why you want to keep it > and why it is useful for you. Though in my opinion a debian/control > file, or generally speaking all information in debian/, should be hard > requirements and either technically necessary for building a package or > legally required. Why should we only include that information? There is other information that is neither, but where it's clearly useful to version it together with the rest of the package, such as the changelog or the description. Or, you know, the Standards-Version for the reasons described elsethread. Also, the Standards-Version header is only recommended to be included, it's not mandatory. If its existence offends you so much and you have so few bugs to fix in your packages that the primary effort of maintaining your package is updating the Standards-Version header then just don't include it? -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Is missing SysV-init support a bug?
]] Simon Richter > A daemon must be capable of running standalone and dealing with the > fallout of depended-on services shutting down, restarting, crashing or > being generally unavailable. All of these are significantly harder to > get right than startup in a SysV environment. A lot of the time, you can just detect it, exit and leave restarting to the init system, assuming your init system supports this. «Don't ever die» is only the rule if the init system lacks that support. (Yes, there are cases where you need to handle errors more gracefully, but having the option of «on error: exit» is useful, especially for simplistic control loops.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Why do we list individual copyright holders?
]] Vincent Bernat > ❦ 1 janvier 2018 17:47 +0100, Jonas Smedegaard <jo...@jones.dk> : > > > Purpose of the Standards-Version field is *not* to keep you busy > > silencing corresponding lintian warning, but to state which version of > > Debian Policy the package is verified to comply with. > > And why is it useful to know something like that? Because you can then you can focus on the particular changes from when-last-synced-with-Policy rather than checking the entirety of the package against all of Policy. > If we don't comply with the latest policy, this is considered a > serious bug. No, it's not. Not complying with policy is anything from wishlist to critical all depending. > We would spare a lot of developer time by not using this field > anymore. I don't think so, I think we save quite a bit of effort by having it due to the aforementioned reasons. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: udftools, pktsetup and init scripts
]] Pali Rohár > What do you think about moving pktsetup into own binary package? Users > who do not need packet writing configuration and only need tools for UDF > filesystem would install only udftools package. udftools is a tiny package, splitting it seems a bit meaningless. > But such thing probably needs more discussion or announcement in > changelog... etc... as existing system configurations needs to be > updated. If you do split it, udftools need to depend on pktsetup for the next release at least so people don't lose that functionality. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: recommends for apparmor in newest linux-image-4.13
]] intrigeri > Regarding RC bugs: I don't think breakage that only happens with > AppArmor enabled should be RC in the context of the experiment we're > currently running: in the vast majority of cases, a local workaround > is available (one can disable the faulty AppArmor profile with the > aa-disable command). I think they (in general) should be RC for whatever is shipping the buggy apparmor profile. Having packages that are broken out of the box is not the kind of distro we should be shipping. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Removal of upstart integration
]] Simon McVittie
> On Thu, 05 Oct 2017 at 21:43:20 +0200, Tollef Fog Heen wrote:
> > However, if you just do the IMO more common sudo $command, you get a lot
> > more:
> >
> > $ sudo env | wc -l
> > 87
>
> Is that under default configuration? My /etc/sudoers{,.d/*} don't mention
> env_reset, and "sudo env" clears most of the environment (including LESS,
> but notably not PATH).
Hmm, no, it seems like my standard setup has snuck in a !env_reset in
there somewhere. With that removed, the environment is indeed a lot
cleaner (~similar to what I got with sudo -i). It still leaks
XAUTHORITY, HOSTNAME, DISPLAY, TZ, LANG, which is annoying, but it's
less of a problem than what I claimed.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Re: Removal of upstart integration
]] Ian Jackson > However, I think that such arrangements are already made. The > majority of people use "sudo", which AIUI already launders the > environment. That depends. If you do sudo -i you get a mostly clean env: $ sudo -i env LANG=nb_NO.UTF-8 TZ=CET SUDO_GID=1000 DISPLAY=:0 HOSTNAME=xoog.err.no COLORTERM=truecolor USERNAME= SUDO_COMMAND=/bin/bash -c env S_COLORS=auto USER=root ENV=/root/.bashrc PWD=/root HOME=/root SUDO_USER=tfheen SUDO_UID=1000 MAIL=/var/mail/root SHELL=/bin/bash TERM=xterm-256color SHLVL=1 LANGUAGE=nb_NO:nb:no_NO:no:nn_NO:nn:en LOGNAME=root XAUTHORITY=/home/tfheen/.Xauthority PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin _=/usr/bin/env So some bits are leaking, compare to: $ sudo su - -c env LANG=nb_NO.UTF-8 DISPLAY=:0 COLORTERM=truecolor USERNAME= S_COLORS=auto USER=root ENV=/root/.bashrc PWD=/root HOME=/root MAIL=/var/mail/root SHELL=/bin/bash TERM=xterm-256color SHLVL=1 LANGUAGE=nb_NO:nb:no_NO:no:nn_NO:nn:en LOGNAME=root XAUTHORITY=/home/tfheen/.Xauthority PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin _=/usr/bin/env so even su leaks DISPLAY/XAUTHORITY. sudo -i leaks TZ, HOSTNAME and adds some SUDO_* settings. However, if you just do the IMO more common sudo $command, you get a lot more: $ sudo env | wc -l 87 It does clean up PATH, but it does not filter out my normal settings, so say, LESS and LESSOPEN leak through to dpkg. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: make dpkg-buildpackage default locale UTF-8
]] Ivan Shmakov > >>>>> Tollef Fog Heen <tfh...@err.no> writes: > >>>>> Ivan Shmakov > >>>>> Hans-Christoph Steiner <h...@eds.org> writes: > > >>> Package: dpkg-dev > > >>> More and more packages are adding unicode files > > >> I assume you mean “UTF-8 filenames” here (per below), right? > > >>> as unicode support has become more reliable and available. > > >> What are the use cases for such filenames? > > > Accurate representation of what they contain. wnorwegian contains a > > file «bokmål» which is the word list for the form of Norwegian known > > as bokmål. There's a convenience link between it and bokmaal so that > > people without Norwegian keyboard (or without compose keys) can type > > it too, but the canonical name is bokmål, not bokmaal. > > It does indeed seem natural, when it comes to packages providing > support for a specific language, to use filenames in that same > language; I’m not going to strongly object to that. However, > I’d like to note that other wordlist packages appear to stick to > English (and ASCII) filenames. For instance, wfrench uses > ‘french’ (instead of français) and witalian uses ‘italian’ > (instead of italiano.) Since Norwegian has two forms of the language, we ship two wordlists. I could have gone with «/usr/share/dict/norwegian - New Norwegian» and «/usr/share/dict/norwegian - book tongue», but I suspect that'd be considered less helpful than just using bokmål and nynorsk. > I’m still curious, are there any other uses in the archive > beside the above? There are at least some files in the ca-certificate package that have non-ASCII names, presumably since the CAs have non-ASCII names. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: make dpkg-buildpackage default locale UTF-8
]] Ivan Shmakov > >>>>> Hans-Christoph Steiner <h...@eds.org> writes: > > > Package: dpkg-dev > > > More and more packages are adding unicode files > > I assume you mean “UTF-8 filenames” here (per below), right? > > > as unicode support has become more reliable and available. > > What are the use cases for such filenames? Accurate representation of what they contain. wnorwegian contains a file «bokmål» which is the word list for the form of Norwegian known as bokmål. There's a convenience link between it and bokmaal so that people without Norwegian keyboard (or without compose keys) can type it too, but the canonical name is bokmål, not bokmaal. (I see there's a small bug where the symlink is the wrong way around, I'll get that fixed.) å is in latin1, though so fonts should not be a problem in your particular case. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Whether remotely running software is considered "software" for Debian.
]] "Dr. Bas Wijnen" > On Thu, Aug 31, 2017 at 11:16:36AM +0200, Ansgar Burchardt wrote: > > python-digitalocean, ruby-azure*, waagent, twittering-mode, > > probably HBCI clients, python3-googleapi, > > python3-pyicloud, python-yowsup, youtube-dl, > > libgfbgraph-0.2-dev > > Thank you for this list. I removed servers that cannot run on a general > purpose system, because for obvious reasons they cannot be included in main > even if they were free software. Then you shouldn't remove usbmuxd for instance. iOS devices are general purpose computing devices, they just run another OS, and there's nothing stopping somebody from implementing the same interfaces using free software and, say, the Linux USB APIs. I'm not sure what OS modern HP printers run, but I would also not be surprised if they run a pretty straightforward Linux. Somebody could implement the APIs and produce, say, PDFs, or print using a hand-built printer. For the first case, you could easily run that on a general purpose system. You say that the requirement for an implementation to be useful is orthogonal to whether it's suitable for main. Does that also hold with s/useful/functional/? -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Whether remotely running software is considered "software" for Debian.
]] "Dr. Bas Wijnen" > But it's running on a different server. How is the "unrar-server" different > from an icq server? The unrar-client would be free software. The value of an ICQ server with a singular user is pretty low. The value there lies not in the software itself, but the network effects and the people you can talk to. Likewise, a lot of the value in using various cloud services is not in the software implementations. It's in how they are run, that there's «always» capacity available and so on. I think this is important, because those are attributes that can't be packaged. Having the source (and redistribution rights) to some cloud provider's software would not really put us that much closer to having what they offer and make them attractive. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: openssl/libssl1 in Debian now blocks offlineimap?
]] Adrian Bunk > On Fri, Aug 18, 2017 at 10:07:49PM +0200, Tollef Fog Heen wrote: > > ]] Adrian Bunk > >... > > The PCI consortium extended the deadline until June > > 2018. Assuming that deadline holds, people with older machines will not > > be able to access services such as online banking or pay online in > > general. > > That's wrong. I'm not sure which bit of the quoted text you think is wrong. > Think of the "TLS 1.2 not working with WPA" discussed earlier here that > might still affect half a billion active Android devices at the buster > release date.[1] > > The online banking app running on such a device will support TLS 1.2 Maybe, maybe not. Depending on how it's implemented, it's non-trivial to get TLS 1.2 support in there. Just doing HTTP or TLS yourself is easy enough, but if you want to use a webview, you're at the mercy of the TLS libs of the OS. > The PayPal app currently requires Android >= 4.0.3, released in 2011. I'd not be surprised if that gets bumped, but that's just my guess, I have no knowledge into what their actual plans are. [...] > >... > > to make sure any users on platforms where support for that is > > lacking get a proper notification and a chance to move to something > > newer. > >... > > Imagine Debian running on the AP providing the WiFi for a Cafe. > > What you are saying is that the staff working at the Cafe should explain > to their customers that they have to buy a new phone if they want to use > the WiFi. Why would that be the case? They're likely to just be using WPA2 or have an open network, neither of which require TLS. Arguing for keeping TLS 1.0 support means you're arguing for providing users with a default-insecure setup. In today's world, I think that's a pretty poor choice. Providing people with the possibility to fall back to less secure solutions sounds like a much better choice, just like it's possible to install an telnetd providing unencrypted logins, but it requires you to actively go out and install it. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: openssl/libssl1 in Debian now blocks offlineimap?
]] Adrian Bunk > Or did this start as a coordinated effort of several major Linux > distributions covering all TLS implementations? While not speaking for Kurt, there's been a move towards getting rid of TLS < 1.2 for quite some time, by reasonably important players such as the PCI-DSS consortium which announced in 2015 that June 2016 would be the deadline for disabling older TLS versions. As we all know, we're past that date now, and TLS < 1.2 is still around and entirely too well-supported. The PCI consortium extended the deadline until June 2018. Assuming that deadline holds, people with older machines will not be able to access services such as online banking or pay online in general. I'm hoping they won't extend the deadline again, but they're pragmatic. As they write in their press release: “…in the field a lot of business issues surfaced…” said Stephen Orfei, General Manager, PCI SSC. “We want merchants protected against data theft but not at the expense of turning away business, so we changed the date.” > Nothing that Debian does alone will have any measurable impact > on TLS 1.0 usage. I think you're wrong on this point, having Debian make this change makes it a lot easier for me to go to company management and explain that TLS v1.2 is the only way forward and that we need to spend engineering resources to make sure any users on platforms where support for that is lacking get a proper notification and a chance to move to something newer. «We need to do this because this change is coming, whether we want it or not.» -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Accepted librt-extension-commandbymail-perl 3.00-1 (source all) into unstable, unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 30 Jul 2017 09:59:51 +0200 Source: librt-extension-commandbymail-perl Binary: librt-extension-commandbymail-perl Architecture: source all Version: 3.00-1 Distribution: unstable Urgency: medium Maintainer: Tollef Fog Heen <tfh...@debian.org> Changed-By: Tollef Fog Heen <tfh...@debian.org> Description: librt-extension-commandbymail-perl - Allow RT status and other commands by email Changes: librt-extension-commandbymail-perl (3.00-1) unstable; urgency=medium . * New upstream version. * Add build-depends on libmodule-install-perl and request-tracker4 * Bump dh compat version. - Remove all hacks from debian/rules, this just works now. * Ship upstream README file with installation instructions. Checksums-Sha1: e3566b1d075ec45c4c90cf621b8f108bfacc0caf 1971 librt-extension-commandbymail-perl_3.00-1.dsc a22b98746c96690c2670c6af221878be6aec5d75 59304 librt-extension-commandbymail-perl_3.00.orig.tar.gz cf72beb977b8c3018f79707bf611bddbf0642c1d 1663 librt-extension-commandbymail-perl_3.00-1.diff.gz 6c35433c8b1379e9a2560cb4d817433e7da7434d 24382 librt-extension-commandbymail-perl_3.00-1_all.deb 21b030ec1cdbb78a9e8958f1c65c5b531e1719b5 15741 librt-extension-commandbymail-perl_3.00-1_amd64.buildinfo Checksums-Sha256: 7b5a821d0fe9523747f7ef0b811f781f264678bbea7cbdb04a12b1c219eb5521 1971 librt-extension-commandbymail-perl_3.00-1.dsc c1a0ccb5472a601a124923cbadf54f8522d02955efc7e5389f96a37efc2c7900 59304 librt-extension-commandbymail-perl_3.00.orig.tar.gz 670ce5db87b70f2f9ea86619534fe3c5f6020735361f7b55f47cdabcb165edb6 1663 librt-extension-commandbymail-perl_3.00-1.diff.gz 67a80293113adb8875344297dfe83c8f9cef78f42b7c441a0c1e3097c1ff8dd0 24382 librt-extension-commandbymail-perl_3.00-1_all.deb 2490c1ae5cf7309b8bb7f321476ac8ea91c858003150715a0a67328c964483fb 15741 librt-extension-commandbymail-perl_3.00-1_amd64.buildinfo Files: 8f53ce19431e4e77faaf087e279d8a22 1971 misc extra librt-extension-commandbymail-perl_3.00-1.dsc e062df6d9f1fea51016f0a06e2798cdc 59304 misc extra librt-extension-commandbymail-perl_3.00.orig.tar.gz b3669face87667cf9cf2b13bc2b26633 1663 misc extra librt-extension-commandbymail-perl_3.00-1.diff.gz 351ca55a1a0f85d852056584717856ff 24382 misc extra librt-extension-commandbymail-perl_3.00-1_all.deb f38f6e8079d09ce525d7dc4c5b7d72fd 15741 misc extra librt-extension-commandbymail-perl_3.00-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEooQRpZYZMXEzGALAtlpIccoZ1xcFAll9rL0ACgkQtlpIccoZ 1xfYWRAAiby/7o0jifpWpi3msNJmwwUy3n3M9emOTw/vcrE5cUp7M96YZ4uBn1uE 4aES/CJB/lbpaYvEiOk7lEJ6N8kUF8wPByZjT/6XIERfG7ghQ6kMexG3OdwFLykZ rX7rtUmjY3XV12pGHU/LyOjErS5q8QR/G1v1tgXqnODfLxoaOyI99WvEErZ5BnJG WSnx67m7qf3AfjtwhTsMxtTTu5wE9Pn1Vo7hzP0dKGhu3n6ka8I3z+RFQjuHRuQ4 KlEvF0w85cntoo0xkuRsBp5sbmWL/D5R/vLrJGU1+I5qClf2vT/shVl/WPIHA7t1 8sZbnISUr+D9jOmZvvVJzlr/VWL1B3qpOClDh4PVSLUdj8aykbXWJEv++l91r3eK nA7b7cfhGFSrG5buOrzBV5ZPItit/VgZX9uTDBb9BOQVNW/v/oWOUna12jvtgtpn IljZcBNHGvdoi5ye5PsK98JRhNG+xsIir38Y6EhUNU39mIsQE8cli/bQ4Gdn/FjX eWvYcu6mxyrYrwagV0KYT6RlVKTApivud36dDyH/Q3amkEtNl+aNf6ObT3cApumU SPgXu8jrTr8grha5qUWUEytX5Mu9SVi280jLaGsNCRtzDWy4GqK2BWcJ68XOE4a4 wEHFIRg119JgSBCiQr/L5boVuinROnNkn+aG7qhrdVkKls51tHE= =FoUB -END PGP SIGNATURE-
Re: OpenSSL disables TLS 1.0 and 1.1
]] Russ Allbery > That doesn't mean we can't make it very easy to disable TLS 1.0/1.1 or > encourage people to do that when possible, of course. It would be great > for us to try to lead the way and push things forward a bit. But I think > we're still going to have to make it very easy to enable TLS 1.0/1.1 for a > lot of people and applications for a bit longer. While I think we might want to ship buster with TLS 1.0 available, I think running with it disabled for parts of the development cycle is very useful, since it exposes bugs we have in packages that will use that version out of the box (isync being referred to elsethread). Finding and fixing those bugs is good. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Accepted norwegian 2.2-3 (source all amd64) into unstable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Thu, 20 Jul 2017 19:57:07 +0200
Source: norwegian
Binary: inorwegian wnorwegian aspell-no myspell-nb myspell-nn
Architecture: source all amd64
Version: 2.2-3
Distribution: unstable
Urgency: medium
Maintainer: Tollef Fog Heen <tfh...@debian.org>
Changed-By: Tollef Fog Heen <tfh...@debian.org>
Description:
aspell-no - Norwegian dictionary for aspell
inorwegian - Norwegian dictionary for ispell
myspell-nb - Norwegian Bokmål dictionary for myspell
myspell-nn - Norwegian Nynorsk dictionary for myspell
wnorwegian - Norwegian word list
Closes: 857781
Changes:
norwegian (2.2-3) unstable; urgency=medium
.
* Fix up where the no{.{dat,multi},_phonet.dat} symlinks point.
Closes: #857781
Checksums-Sha1:
ed0878571d693965ca1f6cda7559c331d26060f9 2087 norwegian_2.2-3.dsc
7d7365e38c531705b66e3648d9f5fa589506560e 17490 norwegian_2.2-3.diff.gz
51f79e3e132cfa15419cddcca8e1756889300d36 13902068 aspell-no_2.2-3_all.deb
03be5663e2465203de8f3062522111cc414df4e7 4377794 inorwegian_2.2-3_amd64.deb
659a32e1533e88de3666a30397562e3efae8c4da 1197654 myspell-nb_2.2-3_all.deb
a6b566e562938857e8cf0db320a22ac80dc569bd 827260 myspell-nn_2.2-3_all.deb
01befa0e129d2c5882820407fb082cd1b53026fe 6878 norwegian_2.2-3_amd64.buildinfo
daa27af1991f589985a38a3c71e30093ef900327 3203236 wnorwegian_2.2-3_all.deb
Checksums-Sha256:
977c59117526b43a45657c3eccfe3ac2029e96eaf0f58a4c214c2a3210f7b1d2 2087
norwegian_2.2-3.dsc
e50fe934f7a15f52801ab19e40d9db81d36804061612c7e11556808daa477000 17490
norwegian_2.2-3.diff.gz
a252054cdb85599c3b2185085cd8a11e0a2a609e9fdcffcebc1dd3f24b83c797 13902068
aspell-no_2.2-3_all.deb
f12e59e860c06c6457c110bf1ae63eb7d93fde91afa22d91d19d047575ca1f7d 4377794
inorwegian_2.2-3_amd64.deb
cbb48f2ffd4855676513142b63486051f0b99c9b99d7562ee36f8e1284e972d5 1197654
myspell-nb_2.2-3_all.deb
b2a922971c9effc62d3723b4f4eca1d73451b42a870653f7559d0e853d2f4e8c 827260
myspell-nn_2.2-3_all.deb
74baf2d486499ff978baf04ee9151e4913075e5b79cf395e3fe32044c08b80a1 6878
norwegian_2.2-3_amd64.buildinfo
59cd3871c7b1ee986496781035f00672bbd3f073f5fc973011e393d87d57d758 3203236
wnorwegian_2.2-3_all.deb
Files:
7e8a2ac3d015b9cc124739c49c506b38 2087 text optional norwegian_2.2-3.dsc
7b314bb370a3e0eea7a0f28286c40039 17490 text optional norwegian_2.2-3.diff.gz
cf6f07ebc0712ff502074441ecb3f7bb 13902068 text optional aspell-no_2.2-3_all.deb
24a9d6a992fab2d07fea51852540bc1b 4377794 text optional
inorwegian_2.2-3_amd64.deb
8537e65daeeda69b6a0fbe37046362ed 1197654 text optional myspell-nb_2.2-3_all.deb
93d4883c0dbe5cd927dd6eb5b4c4e4fc 827260 text optional myspell-nn_2.2-3_all.deb
1977b07966ade45269d2a1a5c229012f 6878 text optional
norwegian_2.2-3_amd64.buildinfo
e17e6f374e2c52986145af839ebfdcc0 3203236 text optional wnorwegian_2.2-3_all.deb
-BEGIN PGP SIGNATURE-
iQIzBAEBCAAdFiEEooQRpZYZMXEzGALAtlpIccoZ1xcFAllw8RQACgkQtlpIccoZ
1xcj5w/+Ju8dnuKA/0YTyf/IZPt2qOTGqOGEnH/+VKzJXBEvWB/f5OxO1k9RQ8RU
cf63HCmnoX8asBCfJynvXUi+El4sy7zj8P8E5kK5XU8QXu7SvmVBL1GltGzWN5UT
RwrSX/wY8aU1wLGIUGyTCZBcb1XPbS75MWmKnZEeSnkzdOuap+bl7oz5ZfCpcvBQ
A5tRdFKeloYgw+WZ88Xkz9LliO4sZeNR/dPoWTMoqBYruQNwf5++HNCC1CEc+CnC
Iy+n3BKmEXslDdnljAfS2fksTPWOaUhAeZhfzFWa3yHUZrN762bl/0FTCQGx9VBZ
egyG11RPeCXq6nJ9qhzzAtGQkV1dKxtr8V6Oa6ZRqRmVngwk9481EOlBu90TaFky
lTnuNEIzB0DiIz87ziH8eDuq5RO0Agn4vITKklkW/R32MV5gT6oLyM1uF6iC35Ub
rvxLclX4WuYNx4p4x9XPCHvBQ8wpyICtLkonRshshtjKRPw69xLbNnMc3FYKuuI8
cq4cR4rkXekMstk4JzoNlwhMj50G0YeTQyEXxxJvYWPHauP9Ln1gZwDM6cden5UP
21J0p4/L77zcuRSWZPV+5LnaRjbijsTmZKKEuUeK4Qpz3riQ8kBM3yzZcKa2pSSW
p9m3ZjdyAbZmQtY7rAC5ZZWPaszAHXqtPtM4R0ArS5wWnFHqAJE=
=cUIh
-END PGP SIGNATURE-
Re: Debian built from non-Debian sources
]] Ian Jackson
> Russ Allbery writes ("Re: Debian built from non-Debian sources"):
> > I think it would be interesting to strive for making available all Debian
> > infrastructure in our archives (although I think you may find that you'll
> > need a separate archive that doesn't correspond to stable or unstable,
> > based on having done similar things in the past), but it would be
> > premature to put a requirement into Policy until we actually *did* decide
> > to do that. Which would affect a ton of different teams, and would be
> > quite a bit of work.
>
> As a practical matter, complex bespoke services are much easier to run
> directly out of their vcs trees.
I've been toying with the idea of running those services from
containers. That would at least get us a runnable artifact, even if it
wasn't purely generated from the archive. (Yes, we'd need to publish
them somewhere and record where they came from and there's a lot of
practical questions.)
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Accepted sash 3.8-4 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 16 Jul 2017 19:13:30 +0200 Source: sash Binary: sash Architecture: source amd64 Version: 3.8-4 Distribution: unstable Urgency: medium Maintainer: Tollef Fog Heen <tfh...@debian.org> Changed-By: Tollef Fog Heen <tfh...@debian.org> Description: sash - Stand-alone shell Closes: 783031 852771 Changes: sash (3.8-4) unstable; urgency=medium . * Add debconf warning about sashroot user instead of trying to remove it, since userdel is unable to properly delete it. Closes: #783031 * Let dh_auto_build pass cross compilers. Thanks to Helmut Grohne for patch. * Stop stripping during build. Also thanks to Helmut Grohne. Closes: #852771 Checksums-Sha1: 0bff59671c2cd40302690445eee3ec30ea45adf9 1770 sash_3.8-4.dsc e4fea7bdcc6b037d75a8c27ca8168dfcae5c727b 16288 sash_3.8-4.debian.tar.xz 4a7201b9bcb7e26ce73bee861914c1c584193ec5 112922 sash-dbgsym_3.8-4_amd64.deb c6a462dac61c6eb280ad68244224e354c7984559 5667 sash_3.8-4_amd64.buildinfo cbf72ff78830602be5b4898f839097779166e230 359070 sash_3.8-4_amd64.deb Checksums-Sha256: 06623608287115148340c86feb8041d33efe46d651cf0210d674fcbb632d82e9 1770 sash_3.8-4.dsc bd98efa102e71ca283bb5efc272bc8472e3b8c32b1151c6fb87cdf2fe676653c 16288 sash_3.8-4.debian.tar.xz 5689069c114bab8be6f878c20458df9c697a1da645052909e2f8ff8b6d71ab47 112922 sash-dbgsym_3.8-4_amd64.deb cc83d9b4a70b17f78213b6899f1f90471eb871b3c2058cf2e7d1901a1bf17f0a 5667 sash_3.8-4_amd64.buildinfo e3f91522488701f25d23123aca371558795894b6d3831b0e188d68aa1781f5d6 359070 sash_3.8-4_amd64.deb Files: 619815ed86e6d5547cd04f76f8fbfbaa 1770 shells optional sash_3.8-4.dsc d993855da04824f7f7b550d3ffcbf203 16288 shells optional sash_3.8-4.debian.tar.xz 09723ca7c965be4b48dea1cedaad2523 112922 debug extra sash-dbgsym_3.8-4_amd64.deb 22048ae34a98ac2bf4d3674239b0044e 5667 shells optional sash_3.8-4_amd64.buildinfo 0bcf7b8d12aa86a4e4e1a798ec53d3b3 359070 shells optional sash_3.8-4_amd64.deb -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEooQRpZYZMXEzGALAtlpIccoZ1xcFAllrpiIACgkQtlpIccoZ 1xdRmw/7BOVvUHarvnCwwTQe4p6wFeOpscRRUzV5XreRO4ctun0wnBkpGRTPUcv9 D5/HBxBmJp5XQabDTw5Uzsp3LpLMjJvp9hqtvwtZrDqFhu2cF1lk57ALV0s4ii8V 9CmwMBM6dcFDygjEH300Fm0V6hXV23kZnT1/cWFBAyG2jjmp58/7h9JKJpznHCw8 MmHQK0X3P3JpqvN+Syk3VElj3wwjChqr8s7Tnm36gAXWkylZyhfH8q37T2Ws6Hab c1poT6WxFdk2FZPjNtTe+PwOafkPqQW9ifqJpqqBxBpRA0KUqkwxWnF1tKGxyqCS X6jRBLu91I/L//4fIizbHApLzPZYjLOCmW5RFggGFF5pJFGlO2l8jz3Egj79SoEE fUpUIvZ586ywuUI/1fUown9ZKx0Gdnfr9qLr8dWIlbzE6BDn2f7DQKsiVyQYLFLE A6cYaE/3XO1NrwzKbxw6nd2dA3JZxGxRMCQJ0J8z1AjCG+feEEXESgCLQI0MHUX4 ZbEcZ+fsYo1KYhTM7lMRjfsnyozEyQgcWOW9OLFz/jbcUXMAqlMJMKKF7huI0d70 d9o7N1BIPeZ775qe332PQ86FEUBk8aBKgVbsjsD8sytSzj6uKI8OkEO188UEpZwa 3tOOUxbDy7ZLKMH2sQ69bUCvIEXW/oH4aTtRNFcw3oAuXz4B3t8= =Uv6i -END PGP SIGNATURE-
Re: Naming of network devices - how to improve it in buster
]] Marc Haber > On Thu, 13 Jul 2017 19:37:52 +0200, Tollef Fog Heen <tfh...@err.no> > wrote: > >]] Marc Haber > >> My finger memory will still type tcpdump -i eth0 before the brain can > >> intervene ten years from now. > > > >In that particular case, I'll recommend you either leaving out the -i > >switch completely or just doing `-i any`. I find it's rare I care about > >what interface traffic happens on. YMMV, of course. > > As a general paranoid type of guy, my foot nails curl up when I see a > tcpdump command line without -i. I don't know where this originates > from. Did tcpdump support the "listen on all interfaces" semantics > without -i from the beginning? I don't think it listens on all interfaces without -i, it just listens on the first one (I think the first one with a configured address, which in the trivial case is the one you want). I don't know why it tickles your spider sense to run it without -i. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Naming of network devices - how to improve it in buster
]] Russell Stuart > As for *.link files, syntactically they like all systemd stuff are a > huge improvement on what came before them. But the old ugly udev rules > have one thing over them - they provide hooks for scripts to cover > cases they haven't thought of. Scripts seem to be an anathema to the > author's of systemd. While that remains true they will never be able > to replace udev rules in all cases. Doesn't something like: [Unit] Description=My hook for foo.link After=foo.link BindsTo=foo.link [Service] Type=oneshot ExecStart=/usr/local/sbin/whatever RemainAfterExit=yes [Install] WantedBy=multi-user.target work to hook into when a link unit is activated? (Or just a Wants and Before in the foo.link unit) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Naming of network devices - how to improve it in buster
]] Russell Stuart > It's not sysadmin's managing fleets of machines. They need persistent > names, but you rapidly go insane if the lan NIC isn't named "lan0" or > something regardless of the machine your platform is running on. So > you end up dropping your own customer files in /etc/udev/rules.d > anyway. At least that's what I do. FWIW, I've (almost) never done this. I generally just use the provided names and don't really care what they are as long as they don't jump around. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Naming of network devices - how to improve it in buster
]] Marc Haber > My finger memory will still type tcpdump -i eth0 before the brain can > intervene ten years from now. In that particular case, I'll recommend you either leaving out the -i switch completely or just doing `-i any`. I find it's rare I care about what interface traffic happens on. YMMV, of course. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: DEP 15: Reserved namespace for DD-approved non-maintainer changes
]] Sean Whitton > Per the DEP: > > > it is very useful for a maintainer to know that a change has been > > approved by someone who has been trusted by the project with the > > technical ability to NMU the package > > This would be much more cumbersome to achieve with PRs. I'm not sure why this is very useful. It can, in some cases, be a useful data point, but in general, as the maintainer, I'll want to review the patch in the same way no matter whether it came from somebody with a key in the keyring or not. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: init system agnosticism [WAS: how to remove libsystemd0 from a live-running debian desktop system]
]] Vincent Danjean > For me, the first argument explain in the first mail is not this > one. systemd is not portable on lots of system (hurd, kFreeBSD, ...), > upstream systemd is not interested in making its code portable, nor to > stabilize its interfaces so that other system init can easily > implement them, [...] While it's correct that systemd isn't catering to portability, large chunks of it is covered by the interface stability promise (see the table on https://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/) so other init systems are free to implement them if they so want. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Non-free RFCs in stretch
]] Sean Whitton > Could you explain why you want to do this with metapackages, rather than > extending the definition of an archive section so that non-free and > contrib may be more finely divided up? The various implementation > problems that have been raised in this thread are all/mostly due to the > use of metapackages. A package can only be in a single section. I'd look at tagging the packages with debtags and doing a debtags search on installed packages instead of faffing with metapackages. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: [openstack-dev] The end of OpenStack packages in Debian?
]] Thomas Goirand > On 02/18/2017 05:14 PM, Andrew Bogott wrote: > > Does this > > announcement mean that the Mirantis apt servers (e.g. > > mitaka-jessie.pkgs.mirantis.com) will also be discontinued > > Correct, I've been told the server would be decommitionned. In fact, I'm > surprised it is still up-and-running. I've explained that some people > could well still be using it, but it didn't seem someone cared. > > FYI, I made a backup on my own laptop, but I don't plan on investing a > dime on setting-up an online service myself. You could talk to Packagecloud and see if they're interested. Not sure what the size of the repo is, their open source offering is for up to 25G. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Bug#853065: ITP: node-md5-hex -- Create a MD5 hash with hex encoding
]] Akash Sarda > Description : Create a MD5 hash with hex encoding node-md5-o-matic provides an md5 function that seems to do the same, can you use that instead? -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Bug#853057: ITP: node-path-key -- Get the PATH environment variable key cross-platform
]] Aarti Kashyap Hi, > Description : Get the PATH environment variable key cross-platform This seems to be a subset of what node-osenv provides, can you use that instead? -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Bug#852816: ITP: node-home-path -- Cross-platform home directory retriever
]] Tushar Agey > * Package name: node-home-path > Version : 1.0.3 > Upstream Author : Lloyd Brookes <75po...@gmail.com> > * URL : https://github.com/75lb/home-path#readme > * License : Expat > Programming Lang: JavaScript > Description : Cross-platform home directory retriever > > This Script can retrieve your Home Directory Do we need a fourth node.js package to do this? We already have node-resolve-dir, node-expand-tilde and node-osenv which all seems to do the same. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Can we kill net-tools, please?
]] Russ Allbery > It's possible that some other tool has abused CIDR notation in this way, > but ip is still the only place I ever see it. It's definitely not common. I picked a few arbitrary networking platforms: From http://www.juniper.net/techpubs/software/junos-es/junos-es93/junos-es-jseries-quick-start/basic-connection-and-configuration-with-the-cli.html: root# set interfaces ge-0/0/0 unit 0 family inet address 1.1.2.31/24 >From http://wiki.mikrotik.com/wiki/Manual:IP/Address : [admin@MikroTik] ip address> add address=10.10.10.1/24 interface=ether2 From http://stackoverflow.com/questions/11225681/interface-configuration-in-arista-eos : localhost(config-if-Eth1)# ip address 172.16.204.4/24 (Arista's configuration manual is a PDF, hence linking to a random stackoverflow description.) From http://dev-random.net/d-link-dgs-3324sr-management-ip-address-configuration/ : config ipif System ipaddress 192.168.2.2/24 Cisco does it differently, and I'm sure some others do too, but the $ip/prefixlen notation is pretty common in the networking world at least. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Auto-detecting -dev package dependences from pkg-config
]] Josh Triplett > Does this seem like a reasonable approach? I think it sounds fine, but please remember that it's pkg-config, not pkgconfig. :-) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Bug#846903: ITP: node-has-gulplog -- Check if gulplog is available before attempting to use it
]] Pirate Praveen > Description : Check if gulplog is available before attempting to > use it Is there a node-has-has-gulplog too, to check for if has-gulplog is available before attempting to use it? This package sounds a bit weird, even as Node.js packages go. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Accepted norwegian 2.2-2 (source all amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 13 Nov 2016 20:15:00 +0100 Source: norwegian Binary: inorwegian wnorwegian aspell-no myspell-nb myspell-nn Architecture: source all amd64 Version: 2.2-2 Distribution: unstable Urgency: medium Maintainer: Tollef Fog Heen <tfh...@debian.org> Changed-By: Tollef Fog Heen <tfh...@debian.org> Description: aspell-no - Norwegian dictionary for aspell inorwegian - Norwegian dictionary for ispell myspell-nb - Norwegian Bokmål dictionary for myspell myspell-nn - Norwegian Nynorsk dictionary for myspell wnorwegian - Norwegian word list Closes: 844142 Changes: norwegian (2.2-2) unstable; urgency=medium . * Turn off parallel builds. Closes: #844142 Checksums-Sha1: 4ce9c5f8a19c43bf1395fe5269421b9c862c63c1 2055 norwegian_2.2-2.dsc 7366e32f12f45d4c242d8a0a3ea4ecd50c532115 17418 norwegian_2.2-2.diff.gz 0dda7fb9782b946c39370bb9bdc3a7a549cb6450 13900924 aspell-no_2.2-2_all.deb 9544ad0e1ccb4a72e7d9b03616cf6f746c54051d 4376266 inorwegian_2.2-2_amd64.deb 7f908804d200aa107789258e33cb779a56e61cdd 1197782 myspell-nb_2.2-2_all.deb ce38cd8e81d021735263589edbac158d8de05996 827366 myspell-nn_2.2-2_all.deb 56ed1c092630fe7d9745d6a474b90d0848c5ccee 5979 norwegian_2.2-2_20161113T192812z-a2b45731.buildinfo 9d509e6b6669c99cb6fb9ef3c543f86292fa8765 3207460 wnorwegian_2.2-2_all.deb Checksums-Sha256: 017129fcc60b1c246869734bdfc80831774da06e243f4d5a4afeac578d45e9e1 2055 norwegian_2.2-2.dsc e7f5aa4f0d128ca72e74716c5f379c537274d6851a35bbf5ab2918f52c647ac9 17418 norwegian_2.2-2.diff.gz b600eca30c51d20149fade07534b8931e4bff701ea1f1ab4637ebd117c4e196b 13900924 aspell-no_2.2-2_all.deb ee213cccfce074dc1201b76bebf0f9eca9028c365900ba4ed3c756bb8a6bb0b5 4376266 inorwegian_2.2-2_amd64.deb 137659f78d943d2394af8bb46c8d95d01414b66e8211cc63610cb9d06ad7 1197782 myspell-nb_2.2-2_all.deb fdb813ed9c6c4db7b7c9991e3cb2de530309d50a9347098176bec5ecb8c70369 827366 myspell-nn_2.2-2_all.deb 3a9003eb880ba957624da9f815ccb123bad154b5c6631e82d27da0c8a87a8994 5979 norwegian_2.2-2_20161113T192812z-a2b45731.buildinfo 575a90d421ac0009366c72baf90d2ad9fc7c8688b9823014e9a65c08901c5baa 3207460 wnorwegian_2.2-2_all.deb Files: 64d0f3e96d370b0f93785928fa5c838e 2055 text optional norwegian_2.2-2.dsc 50150fabd884c85e0fd4069c6ae5039b 17418 text optional norwegian_2.2-2.diff.gz 116cdd962c7dd0949a35f6efd464cbc8 13900924 text optional aspell-no_2.2-2_all.deb c731c10657b043571f9279075de8198d 4376266 text optional inorwegian_2.2-2_amd64.deb 881d11388cf3ae682d5f2cb0f8749b82 1197782 text optional myspell-nb_2.2-2_all.deb 78a58df6200248587ec49e683d040361 827366 text optional myspell-nn_2.2-2_all.deb a2b45731a72d96c23adc74418a4db6b9 5979 text optional norwegian_2.2-2_20161113T192812z-a2b45731.buildinfo 33b209d4e4e4455f3e8b4ed90e7a9d75 3207460 text optional wnorwegian_2.2-2_all.deb -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJYKL8BAAoJELZaSHHKGdcXZeoP/jTpeBlYuLmp8t72oCvZd/CS 7ryieLbtg8gubFOO/U/K28Qv3NxrEps9R1xzd5ODUix5mAqxYViI1so/p9AxMeo0 pluIfD1tB9NBe9N+vRpv5zafOM5C8VRspNFlwK7xQNNi/YeaflEAIwJIZKsj3ejL hPQvFDcFxwUbrAykl0tod371QsaICifkTI5QbSLFIhZl4MsYUtIG3TqrESHe0O27 pZ+ayNqTBodIp1PRaWb6utOn8iyAH4lLwCLTzG2dgUSD7zAKfahBukZDPr8LSett DazssCdsN5DUkSxtYCTJYwtk1FWfvtFdMitkz1osKw/lilTCLdKp0dyrgYSl0ffe Ye9e67aZzyb0/gjAzfo8dzirNSvTf7dRniQkp4/+R4gvRE+dTmXrcfNY1stzKzZv waqJG8IsetAioxAUTaNgoMpJkLOWwrkI3Tf9qQuT8uvlhFFEXpyxHW5epMSFgOlc SH72pLNGPZ4v1yhiJiuA4LDfWrlqNOodaVKgaBt8EROrA7qd4O62zuEv5dnxxxhi 3NYeEc34jxkw2xfg8FsY69WS2oBEMfzXfleo3t4b0hVqALXNr+ro2WjldjzNfReD W8PQHxGmt+CYGvs/FjIjbso6txRexigXMECNzMAhrgeBDmgD+LyR8aUGs9HfcnrE FDQyfIthCRtF3YSriVec =0Oge -END PGP SIGNATURE-
Accepted mlocate 0.26-2 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Sun, 13 Nov 2016 13:24:24 +0100
Source: mlocate
Binary: mlocate
Architecture: source amd64
Version: 0.26-2
Distribution: unstable
Urgency: medium
Maintainer: Tollef Fog Heen <tfh...@debian.org>
Changed-By: Tollef Fog Heen <tfh...@debian.org>
Description:
mlocate- quickly find files on the filesystem based on their name
Closes: 700094 711323 720465 762172 786433 791762 810670 810902
Changes:
mlocate (0.26-2) unstable; urgency=medium
.
* Add support for nocache(1) to cron.daily. Closes: #711323
* Update Homepage URL in control. Closes: #791762
* Add /var/lib/os-prober to PRUNEPATHS. Closes: #810670
* Add /var/lib/ceph to PRUNEPATHS and ceph as fuse.ceph to PRUNEFS.
Closes: #786433
* Add fuse.rozofs to PRUNEFS. Closes: #720465
* Update name of mfs to fuse.mfs in PRUNEFS. Closes: #810902
* Add devtmpfs to PRUNEFS. Closes: #762172
* Add ${misc:Depends} to Depends in control file.
* Switch to dh for the build system and bump compat to 10.
- Drop debian/mlocate.dirs
- Drop most of debian/mlocate.install
- Clean up debian/rules
- Add debian/mlocate.docs
* Drop gitpkg scaffolding.
* Add dh-autoreconf to build-depends. Closes: #700094
* Make updatedb man page a slave to update.mlocate manpage, to make
lintian happier.
* Update Standards-Version. No further changes necessary for this.
Checksums-Sha1:
16b7f232a055731b54252a46c1d531eebfa12ea5 1772 mlocate_0.26-2.dsc
ad972d097847dbef541fa9df692c7a29f4493079 7338 mlocate_0.26-2.diff.gz
547273a3dacb18966a0eea5f9b0ab74c61d1b296 89610 mlocate-dbgsym_0.26-2_amd64.deb
b8bed79c5e07116935074ffafd28312feef85c95 4678
mlocate_0.26-2_20161113T191129z-f2472fd4.buildinfo
7ece323cab46e7519dc40d9a04e0a2b098d1cf39 96548 mlocate_0.26-2_amd64.deb
Checksums-Sha256:
9cbb5a7de01d4de79761329f5b741d73e483a996b5618b338bddbda768de7e93 1772
mlocate_0.26-2.dsc
f4eb0df649afc850f883697a6301c7ec39cb97cba56f2b798d570c9d8e1e773f 7338
mlocate_0.26-2.diff.gz
d1a490d6c0e9ebba485d4815053e1e30c4c312e9ecc986f1f4b98d8175dbf1ee 89610
mlocate-dbgsym_0.26-2_amd64.deb
0da5dc7dc3c61da442ee22a276f8c8dd6046d5d6eea4b25da383e7ac7d240d6d 4678
mlocate_0.26-2_20161113T191129z-f2472fd4.buildinfo
b7f91ee4f905ded2b2c807d6101a4cd9d09240251f923edbc0840242e035c300 96548
mlocate_0.26-2_amd64.deb
Files:
b469dfe0639a2e5c08c40305d1ddcd89 1772 utils standard mlocate_0.26-2.dsc
6312ae915ae185e18ca44ebc1b4b0d45 7338 utils standard mlocate_0.26-2.diff.gz
82fa50bc3cbd5b136a6adc9af4bb9c92 89610 debug extra
mlocate-dbgsym_0.26-2_amd64.deb
f2472fd4b838f4b1cf5c46947e0f9865 4678 utils standard
mlocate_0.26-2_20161113T191129z-f2472fd4.buildinfo
4a20a1e0f4ef31709fc6f188ec8bd23c 96548 utils standard mlocate_0.26-2_amd64.deb
-BEGIN PGP SIGNATURE-
iQIcBAEBCAAGBQJYKLtaAAoJELZaSHHKGdcXKucP/2077DDfyyHOi2fqNKuwQhOX
aHv4+fFIFBrUcYfCHvT1rt+1321hHdijNsk6e/6fb5TLLVor4DFqXUkLc05fQlmd
ZZ/GYqafjfW4V2zkvo5Izi1nAUJlUgVMqvB2FNmM06XMWggC9sav9YdEh+TU3bA5
rer2L4rEyYjZ+CLPTohorvnFz7KAv5Y2xuoN+Y4KnxSSwsS+xgWlHUvsiRWwB8en
5EA/cCEy8U6Ymko/cx41yE8k76NkJwDuvtVR7HCPYiTc4yMNsTjRQ06ucls95tSH
iCzyk1KMOXc4Nke0pzEHBbyliR/LeA4NR9q/DYI5jJeTu2ZDdfCETTYACMj79FJq
MtItGNOBOZQsqhakBH/yFQcFdwa9HV14oWhvT4Hbpsx7fnB5gDkV2DTnEPNaXNhO
xNN+7JENWosNrP0F2PS79Phztagk/kJpn15Xq8Vv3w+ESTnpDzX+nDhxgzlKvFK4
a81N8TOXroIDyucsd7CdJ0l4PosdZlJtl3ImqUy9xmGUUOWpaaUyo0Jp8CIcjNjR
jAQ1rpNOOMb51nMmYIVI5rrFGXtUbVKd6iOf5osKnCorwlaf6oQO5E1Jds7PvmFc
+o+LuTg2GX2R3Cn58gIpoIGEBETFF8qw+cdrNRY1PbbhSmRPK8SXS0c92x/bG+EY
UFUe5PTtQ/199pkUcB3P
=T7Sh
-END PGP SIGNATURE-
Re: More 5 november in the release schedule
]] Marc Haber > On Thu, 10 Nov 2016 00:24:20 +0100, Wouter Verhelst > <wou...@debian.org> wrote: > > >If the release team is willing to consider exceptions when > >the automated machinery was jumping the gun a little, however, then > >okay, I think it might be a good idea to try this out. > > If you only get an exception if your package is so important that the > press will mention us like "Debian stretch is missing the important > foo package", then I wouldn't want to even try this. If getting an > exception is the normal case, then, fine, try it. But why would be > bother to write this in policy if we intend to do this as the normal > case? I don't understand why you think the criteria for allowing a package back in is «is important». It might just as well be «is the maintainer doing an honest effort here, or is it just a drive-by upload?» or something else. I'm not going to pretend to be able to read the release team's collective mind. > >Being rigid about such policies is never a good thing, though. > > Yes. And I am afraid that this policy is being as rigid as a two inch > steel wall. It sounds like you have had very different interactions with the release team than I have. In my experience, they're doing a difficult job, and doing it well, trying to accomodate everybody while still making progress towards releasing. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Bug#842306: ITP: falco -- Sysdig Falco is a behavioral activity monitor designed to detect anomalous activity in your applications
]] Julien Rabier > Powered by sysdig’s system call capture infrastructure, falco lets you > continuously monitor and detect container, application, host, and network > activity... all in one place, from one source of data, with one set of rules. > > I use Sysdig and Falco professionnally and would like to package and maintain > Falco in Debian. Yay, great to see this packaged! I've wanted to poke at it for a while, but ENOTIME so far. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: When should we https our mirrors?
]] Adam Borowski > Despite many fast mirrors nearby, deb.debian.org almost always connects me > to a server in the US (I got NL just once). Tried from three ISPs. Is this on IPv6 or legacy IP? The former is known to be less-than-ideal routing-wise in a bunch of cases and I'll talk to Fastly to see if we can get a process to get this improved, but this should be rare(r) for legacy IP. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: When should we https our mirrors?
]] David Kalnischkies > I would kinda like to avoid encoding the entire answer and sending that > in for display because it would be a lot of noise (and bugreporters will > truncate it if it is too long trying to be helpful), so if people who > actually know what they would need to deal with issues (I don't) would > decide upon a set and report a bug against apt to implement it, we will > see what we can do. It would be great if we could have all of it (dropped in a log file would probably be ok, we can then ask for it from the user). > P.S.: Fastlys Via response header seems to be important, given that it > is sent twice, but apart from that… Not really, it's just that it passes through multiple caches on the way. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Accepted norwegian 2.2-1 (source all amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 26 Oct 2016 21:54:36 +0200 Source: norwegian Binary: inorwegian wnorwegian aspell-no myspell-nb myspell-nn Architecture: source all amd64 Version: 2.2-1 Distribution: unstable Urgency: medium Maintainer: Tollef Fog Heen <tfh...@debian.org> Changed-By: Tollef Fog Heen <tfh...@debian.org> Description: aspell-no - Norwegian dictionary for aspell inorwegian - Norwegian dictionary for ispell myspell-nb - Norwegian Bokmål dictionary for myspell myspell-nn - Norwegian Nynorsk dictionary for myspell wnorwegian - Norwegian word list Closes: 790765 802950 811513 821373 Changes: norwegian (2.2-1) unstable; urgency=medium . * New upstream version. - Fixes FTBFS. Closes: #790765 - Add missing scripts/thes_to_dat script from git. - Add libmythes-dev * Add Brazilian Portuguese debconf translation. Closes: #811513 * Add Homepage field to control file. Closes: #821373 * Always use gawk as the awk. Closes: #802950 * Bump to debhelper 10. * Install hunspell files in hunspell, drop installing myspell links. * Fix formatting of Build-Depends. * Make aspell-no Arch: all * Bump Standards-Version to 3.9.8. Checksums-Sha1: ba59f5ed281c16288eb90ecf076a81b0c37edb4e 2055 norwegian_2.2-1.dsc dd5025640213c7b4ac510a6dd7303b0eb34fb2f2 5539105 norwegian_2.2.orig.tar.gz 07bf0ffacfe916bae71ecfda2f36fdcc9e78b537 17305 norwegian_2.2-1.diff.gz 0606eb6e0379017a2f487dacd82a5190325c0c52 13913408 aspell-no_2.2-1_all.deb 8a6d4179a2c9e3edfafea380dc0c063a8c249813 4378136 inorwegian_2.2-1_amd64.deb ad876ee8662cb3785e535b5166ab06a2dad92a2b 1197722 myspell-nb_2.2-1_all.deb 887ae280fd9e2006eb76f05a8f8c590867d7f23d 827076 myspell-nn_2.2-1_all.deb fb4c6f9fb762fe7761d461ed5c80e86a5ae8e83c 3205814 wnorwegian_2.2-1_all.deb Checksums-Sha256: 3add18f1ba027630f2cae4d7784d7f5e3c93bda21f4e19e80f05cff76f5d6a8a 2055 norwegian_2.2-1.dsc ad9d7e1acec454bad2bfa2fe618b3fecb438e86cc5181e0932598f935209bf23 5539105 norwegian_2.2.orig.tar.gz 1d8bb2ae1d40bd8931a74ce52a1fd0c15de0bb2e1debdb51160cb981837712f2 17305 norwegian_2.2-1.diff.gz da0628bfed7a1042633a21204502f2512f0519588e745635b1fdb6693e869556 13913408 aspell-no_2.2-1_all.deb 6f0e82f5d72cf2a8590edf4d4cf9e357f8314f5f3be2c8abc9d4adb40c945d0a 4378136 inorwegian_2.2-1_amd64.deb 863cafc3d2b3ab5a942f9273bdde40d1bc63e3371eeea51094bcb2dd4241035e 1197722 myspell-nb_2.2-1_all.deb 297a9a2c63b74509b8807c0ae892161c533785d24df3c64f9878bc059677500d 827076 myspell-nn_2.2-1_all.deb 43f397a405fb72f367fb56692a237ff4889626b6200ee2ae486763e143996949 3205814 wnorwegian_2.2-1_all.deb Files: 856888b8d70da581dd5932832194f174 2055 text optional norwegian_2.2-1.dsc bb8d190294c840c3947748aaa5616b00 5539105 text optional norwegian_2.2.orig.tar.gz 90d1d0fa8dd76fc8b29bc6b0e1d9224d 17305 text optional norwegian_2.2-1.diff.gz d904b9a80df64fec761113f00a7d1993 13913408 text optional aspell-no_2.2-1_all.deb 9ef955f5480b6f822c293db9e611b18e 4378136 text optional inorwegian_2.2-1_amd64.deb c83a04ffa36deaf154da306d0a062fa8 1197722 text optional myspell-nb_2.2-1_all.deb 9765a8b795a444a0a27ad65f211da011 827076 text optional myspell-nn_2.2-1_all.deb f5c661df755eaf9ab8eef66c0edc08b1 3205814 text optional wnorwegian_2.2-1_all.deb -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJYER/FAAoJELZaSHHKGdcXRToP/0tyNc2wiWcCefS9pgry2nqN 4phGbzDUftW+FK39fEmWhU0lFFJc0ozCxxVa/DAaVslMZ1UaDgu+aoqtLa3Ey7NV c8GRtiowUDLwAogyHK7ImQG90E4Z23d0V8lZunExko36lFpDD0EzLrfWRkBMRk3Z 3HbG4gFyXqZOJAaRykjw/nQjH8eBfEPPwUIYdz72CtoVbfVPGc6bHJ5HaNEsE26O DCWxe2SolDDc1PM4LIgFoXk4Kq7vZ2WsbNBjhQinKMFhzjt4iVIqkvtHILukeqa1 q+3LtD/L2J4B6erRSnPaoA6WAz7eGAbzrCdP12KHqbr1OcScfW1LvM4QxTKm4e3K rrJdOUuLiOTYTfYRIlw4ASWjLYIW8vRD/dqkWxPFZbBmvFxEgQ+8Kmk/TcysPrvD CdjdfSktxvl8IaW2FSBH4mNEPocAIDWIT8qCHSm5PpGqwLie+vMhLNr4cukVLkW4 cj0zmZnB/SU4AWCiS9D+4vdrp7dfE1sh3szJ5vRWxH99lgMU7G3/7CuZI+T5V6+G m4Gc1NzrwKBAkphNA8nqSC9g1RTHNrU51TQoceIgSbPZHMHAhYJ/dLPUlpvQ0bdE zdKfPU71sc4w/hFQBkOxj9M3yM3v2mipQiGn6YJvWcrBf9j30geqGXXegsp1KKeX O+TA8b4jc7cC7KinRdei =FkOX -END PGP SIGNATURE-
Re: When should we https our mirrors?
]] Paul Tagliamonte > On Mon, Oct 24, 2016 at 04:00:39PM +0100, Ian Jackson wrote: > > It is also evident that there are some challenges for deploying TLS on > > a mirror network and/or CDN. I don't think anyone is suggesting > > tearing down our existing mirror network. > > https://deb.debian.org/ is now set up (thanks, folks!), so my attention > is now shifted away from the push to https all the things (not everyone > will, so I just want a stable well-used domain that could be a sensable > default, and let those who don't want to move forward stay in the past) > and on to considering the apt https transport and thoughts on how this > could become part of the base install. Note that the performance of HTTPS there is worse than for HTTP due to a lack of SRV support in apt-transport-https, though, which means it falls back to doing HTTP redirects. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: When should we https our mirrors?
]] Philipp Kern > On 10/18/2016 06:47 PM, Marco d'Itri wrote: > > On Oct 17, Ian Campbell <i...@debian.org> wrote: > >> Have we gotten to the point where we consider deb.d.o suitable for > >> production use? The web page still says Experimental (so I would assume > > I do not think that it is appropriate for general use, since at least > > one of the CDNs backing it lacks nodes in many (most) countries. > > I like to get my Debian packages over peering links. :-) > > It's also a little awkward that apt does not tell you which of the SRV > records it picked. (The "and why" is clear: round robin.) I had a short > read earlier today and I had no idea how to even report it without that > information. (Of course I know how to turn on debugging but then it > picked a different one and succeeded.) Even getting the SRV record won't help much, you want to know what IP it resolved to and what headers you got from the backend to uniquely identify problems with a single POP or machine in a POP. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Keysafe dynamic UID
]] Christian Seiler > On 10/24/2016 12:42 AM, Colin Watson wrote: > > On Sat, Oct 22, 2016 at 02:57:23PM -0700, Sean Whitton wrote: > >> I am packaging Keysafe,[1] and the binary package keysafe-server needs > >> to create a new system user with a dynamically allocated UID. > >> > >> I am using the username 'keysafe'. I do not anticipate any collision > >> with any other package, but policy says I should e-mail you to confirm > >> that. > > > > Policy should probably only suggest emailing the base-passwd maintainer > > in the case where you need a statically-allocated ID > > The requirement to have this for dynamically allocated IDs also > probably stems from the fact that the users created in postinst scripts > should not conflict. But wouldn't it be far easier to just create a > page on the Debian Wiki and track that there? [1] And have policy say > to check that list to see that it's unique and add your package + user > there when you are about to upload a new package? That way, in 99.9% of > cases where users are required, and they don't conflict with existing > ones, there's no additional work for people other than the package > maintainer, and the package maintainer doesn't have to wait for a > response before they are able to proceed. And if there really is a > conflict, people can still post to -devel about it. I'd prefer if user creation was just done declaratively and then we could scan the archive. If we have a manually-maintained list, it will get out of sync with reality pretty quickly. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Bug#820036: No bug mentioning a Debian KEK and booting use it.
]] Ian Jackson
> Tollef Fog Heen writes ("Re: Bug#820036: No bug mentioning a Debian KEK and
> booting use it."):
>
> > So far, I don't believe there are any.
>
> this is rather discouraging, at least for those who think this signed
> image malarkey is useful.
Just so we're not misunderstanding each other: I'd love for there to be
something free in this space, and I think signed images are useful. My
statement is just pointing out that (AFAIK), there aren't, and so
spending effort that benefits no users doesn't sound like a terribly
good way to expend effort. I'd love to be proven wrong about there
being a free (and useful) implementation out there.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Re: Bug#820036: No bug mentioning a Debian KEK and booting use it.
]] Ian Jackson > Ah. Maybe it would be worth doing anyway. There might be machines > which work with some kind of libre firmware. But of course actually > doing this depends on someone having the effort. If there are machines with free firmware that also support secure boot, we can look at this. So far, I don't believe there are any. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: When should we https our mirrors?
]] Ian Campbell > Have we gotten to the point where we consider deb.d.o suitable for > production use? The web page still says Experimental (so I would assume > "not production yet") As of this morning, the bit about experimental was removed from the web page. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: When should we https our mirrors?
]] Aron Xu > To make it clear, content delivery systems used by pypi and npm don't > work for many people in China because: > > 1) Major global CDN providers don't have decent services in the > country (except akamai and cloudflare but need special contract); > > 2) BGP based network topology discovery never work because eBGP > routing is not widely deployed for subscriber network; While I sympatise with people in China who have less than stellar access to the entire internet, I don't think we should give the rest of the world a worse experience just so everybody has the same set of problems. At the same time, if we can design a solution that works well for everybody, that's of course preferable. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: When should we https our mirrors?
]] Dimitri John Ledkov > I'm not a sysadmin. My naive approach would be to have cname specified > on the certs that are subject to redirect. E.g. ftp.d.o should have > cname's for all country codes, such that any country mirror can fall > back to ftp.d.o. This would restrict us to always point a ftp.XX.d.o name to ftp.d.o. Sometimes, it'd be more appropriate to point it to a closer geographical mirror. (Say ftp.nz were performing maintenance, it'd be a lot more reasonable to send that traffic to Australia than to the Netherlands.) Is this impossible to fix/work around? No. However, it requires more thought and design than just slapping a few letsencrypt certs onto some hosts. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: When should we https our mirrors?
]] Paul Tagliamonte > So, when are we going to push this? If not now, what criteria need to > be met? Why can't we https-ify the default CDN mirror today? The usual crypto answer: because key handling is hard. Doing this for the per-country mirrors means that repointing mirrors becomes a lot harder than it currently is, and this is something we do on a daily basis. We'd need a solution for deploying the TLS cert for, say, ftp.de.d.o to ftp.se.d.o (or ftp.d.o) if ftp.d.o is down for maintenance. Doing this for deb.d.o would mean we need to get certs on both Fastly and Cloudfront deployed, which is, frankly, a more realistic proposition than jury-rigging something on the per-country mirrors. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Debian does not have customers
]] Bart Schouten Your client seems to word-wrap poorly. > Russ Allbery schreef op 24-09-2016 2:48: > > > I guess I'm finding it quite remarkable how much concerted effort > > seems to be going into try to make me feel ashamed of my behavior in > > some way, which is how I read "feel like excuses." > > Not ashamed, just bad ;-). So you're flat-out saying that you're intentionally behaving like a dick. Go away and don't come back until your behaviour's changed. People trolling and behaving like dicks are not welcome in Debian. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Bug#837606: general: system freeze
]] The Wanderer > I suspect that, from his perspective, closing the bug report _makes_ > that report "disappear with no response" - or, at least, that it makes > it do so to a greater extent than leaving it open with no answer would > do. Closing bugs don't make them disappear, we're not deleting them. > "Bug report filed, remains open indefinitely with no response" comes > across as "no one cares", true - but "bug report filed, closed without > attempting to fix" comes across as rejection of the report, and > therefore, of the idea that the report represents a valid problem. It's > easy to see how the latter is a stronger negative than the former. I'd be much more annoyed at not getting a response than «your bug report lacks crucial detail needed to debug the problem». The latter is actionable on my part (I can try to find the information/answer the questions). In the former case, was there something wrong with the bug report? Did it even reach a human? Did they just not care? It's hard to know, and it's completely inactionable (unactionable?) from the submitter's point of view. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Is missing SysV-init support a bug?
]] Gerrit Pape > A good convention for service programs would be to functionally test for > services it needs very early on startup, and fail if dependencies are > not available. The service supervisor (any modern init scheme seems to > now support this) relaunches eventually, until all dependencies are > fulfilled. Consequently, if while running one of the needed services > fails for some reason, fail also. Supervisors are going to bring things > up again. That's how runit does things. > > If the initialization of some (bloat) service program really is that > expensive before it can functionally check for dependencies, it could > implement the wait-and-retry on its own. I don't think it's a good idea for random daemons to implement support for «wait until a particular file system in fstab is mounted», which seems to be what you're advocating for. Also, having this support in every single daemon means the local admin is at the mercy of various upstreams to implement this support (of which some portion are going to go «I don't want to implement that»), rather than having it implemented once, correctly, in the init system. The waste of CPU cycles is the least of the problems dependencies try to fix. Incorrect operation is a much more interesting one. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: libsystemd
]] Jonathan de Boyne Pollard > Russ Allbery: > > > I think that... says the same thing I said? > > > Read again, and let your eye dwell upon Laurent Bercot's name this > time. (-: The world has changed since 2014 and the Debian systemd > packaging Hoo-Hah, and I've been keeping tabs. s6 doesn't seem to be in Debian and falls under Russ' «That said, my statement is almost certainly wrong in that it doesn't take into account the many less well-known init systems, some of which almost certainly have something like this that I'm not familiar with.» clause. Until it's packaged, I think it's pretty irrelevant to our discussions here. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Is missing SysV-init support a bug?
]] Bart Schouten > You will now demonstrate your superiority by claiming you know the > better spelling? It has nothing to do with superiority. It's just that it's a tad tiring to see it misspelled, just like it gets tiring to see people write Micro$oft and other similar «funny» misspellings. If you don't want to detract from your message, don't add intentional speed bumps to it. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Policy 12.3: should I rename?
]] Wookey > On 2016-07-23 18:58 +0200, Tollef Fog Heen wrote: > > ]] Geert Stappers > > > > > FWIW I agree with both '"main package "should have documentation' > > > and 'additional documentation in separate doc package'. > > > > I think we should stop recommending documentation be put in a separate > > package and tell people who don't want docs to exclude the relevant > > parts of /usr/share/doc using dpkg excludes instead. Disk space is > > pretty cheap and we keep complaining about the per-package overhead in > > Packages.gz, so it should be a net gain for most people. > > Wouldn't that apply to all packages, as opposed to being able to > choose docs-or-not on a per-package basis if installing the packages > or not? Being able to chose this per-package rather than in-general > seems like something that has value. But perhaps dpkg excludes let me > do this per-package too? dpkg excludes are path based, so you can exclude a single package (or exclude all and include a single one, etc). -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
