Re: Suggestions about i386 support
On 2024-06-10 at 08:09, rhys wrote: > On Jun 10, 2024, at 01:44, Andrey Rakhmatullin > wrote: > >> On Sun, Jun 09, 2024 at 08:39:27PM -0500, r...@neoquasar.org >> wrote: >>> Reuse is better than recycle for complex things like electronics. >>> >> You were suggested to resuse an old amd64 machine. > > Again, that assumes that I have such a thing. I don't. Unless you > want to provide one? > > Also, that still doesn't explain how that means the existing 32-bit > machine stays out of the waste stream. In your solution, it doesn't. > In my solution, it does. I think the suggestion was to take an old amd64 machine out of the waste stream, and put the existing 32-bit machine into the waste stream, so that the total amount in the waste stream remains the same but you no longer need software support for the 32-bit machine. How to get access to the right parts of the waste stream to be able to pull out some working 64-bit hardware is another question, and one where I don't have an answer that wouldn't involve spending money (which would presumably make the proposed alternative insufficiently comparable, since presumably you wouldn't have to spend money to keep the existing 32-bit machine in service). If Andrey does, I'd be interested to learn it. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Default font: Transition from DejaVu to Noto
On 2023-09-12 at 02:28, Fabian Greffrath wrote: > Hi Wanderer, > >> Rather than discussing only Noto vs. DejaVu, is there any >> possibility of reintroducing Bitstream Vera as a default-font >> option (even if with a low priority), for systems which have that >> installed? > > can you even see a difference between Bitstream Vera and DejaVu? The > latter should be identical to the former, but with wider glyph > coverage. The fact that I am not sufficiently certain about my answer to that question is the reason why I had not previously replied since Gunnar pointed out the connection. When I was flailing about after the introduction of Noto as first preference, one of the steps I wound up taking appears to have been the removal of the fonts-noto package. If that had been enough to restore the look I was going for (as presumably would have been the case if DejaVu were enough to provide that look), then presumably I would not have felt the need to keep digging and experimenting, much less to have gone so far as a user-profile custom copy of 60-latin.conf in order to reintroduce Bitstream Vera. Unfortunately, six months or so later, my memory of the specifics of what I did or how I reacted at each stage of the experimenting is not clear enough for me to claim that I can in fact see a difference between the two. In looking at depictions of DejaVu glyphs and Bitstream Vera glyphs online, I have seen apparent inconsistencies; some such depictions I found seem at least superficially identical, but I found at least one case where I saw visual differences that I suspect I would find off-putting if used in "production" rendering. I have been considering how best to test this in something like a live environment, and have not yet settled on something that seems both sufficiently doable in my setup and also sufficiently likely to produce accurate results about my observations. If I can find such a method, and it does show that I see differences, then I will probably return and report about that. If I do not see differences, then I may either return and report that (and apologize for the noise, and probably drop the custom config file for the future), or just remain silent to avoid adding further noise. If I cannot find such a method, then I will probably remain silent - and continue using the custom config file - until such time as that changes. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Default font: Transition from DejaVu to Noto
On 2023-09-09 at 23:23, Paul Wise wrote: > On Sat, 2023-09-09 at 23:08 +0200, Gunnar Hjalmarsson wrote: > >> My personal view is that it is a change in the right direction, and >> I have taken a couple of follow-up steps in Debian. There are still >> loose ends and more work to be done to achieve a consistent >> configuration in this respect. However, before taking further >> steps, I feel there is a need to reach out to a broader audience >> about the change. Hence this message. Basically I'm asking if this >> move towards Noto is desirable and, if so, I plea for relevant >> input for the completion of the transition. > > Personally, I found Noto Mono to be very ugly in comparison to the > DejaVu fonts that I was used to, so my knee-jerk reaction was to > override the fontconfig settings to avoid all of the Noto fonts. While I concur and have done the same, I am not sure why DejaVu is the alternative default under discussion. Prior to the switch to Noto, the default preferred font family (listed first in /etc/fonts/conf.d/60-latin.conf) was not DejaVu; that was, as it still is, listed as the second preference. The font family listed as the first preference was Bitstream Vera. The change made appears to have been, not moving Noto up in the list from a lower position, but rather replacing Bitstream Vera entirely with Noto. I have just grabbed version 2.13.1-4.5 of fontconfig-config from snapshots.debian.org to confirm. Comparing preference order 60-latin.conf from that version against the one from the package version currently installed on my system, I see: 2.13.1-4.5 2.14.2-4 Bitstream Vera firstnot listed DejaVu second second Noto not listed first If the intended design is that people who prefer one of the lower-priority entries in the 60-latin.conf lists should remove the packages that provide the fonts listed with higher preference priority, then it seems problematic for the former highest-priority option to be omitted entirely. Rather than discussing only Noto vs. DejaVu, is there any possibility of reintroducing Bitstream Vera as a default-font option (even if with a low priority), for systems which have that installed? For myself, I have worked around this (since March, when I first noticed the change) by copying the 2.13.1-4.5 version of 60-latin.conf into ~/.config/fontconfig/conf.d/. That approach appears to mean that I will miss out on any potentially-desirable changes that may be introduced in this file in the future, but it was the only way of bringing back Bitstream Vera as the preferred default font (without risking having the changes overwritten on a future package update) that I could find. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: 64-bit time_t transition for 32-bit archs: a proposal
On 2023-06-07 at 03:19, Sune Vuorela wrote: > On 2023-06-07, Paul Wise wrote: > >> On Tue, 2023-06-06 at 09:33 +0200, Helmut Grohne wrote: >> >>> I've been reading the discussion around i386 a bit and found the >>> direction it has taken a little unproductive. >> >> I note that there are a number of packages available on i386 but not >> available on amd64, is anyone planning on an MBF about this issue? > > I got curious. Some of them are hurd specific. Others are a i386 > specific version, either for fewer processor capabilities or just a > specific one, like sigend bootloader packages and such. Lets remove > those and see what we have left. > > oh. and a few are miscategorized. And some binary-only non-free. > snes emulator. last upstream release 2007 >> zsnes deb otherosfs optional arch=any-i386 FWIW: though I haven't touched it in quite some while, I recall from all those years ago that the reason zsnes is i386-only is that part of its code is hand-written assembly language for (some variant of) that architecture, and that rewriting it for that not to be the case would be at best impractical. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Is an autogenerated configure shell script non-editable source
On 2022-12-09 at 14:58, Russ Allbery wrote: > Bart Martens writes: > >> That file may be available online for this particular software. >> The debate is about whether such configure.ac file must be included >> in the distributed package for making the package dfsg. And more in >> general, about where to draw the line on how easily editable >> (think: time well spent) the included source code must be for >> making the package dfsg. In my opinion there is no sharp line, and >> ftpmaster is well positioned for making fair choices in a +/- >> uniform way for all packages. And there is always be room for >> questioning those choices and allowing the meaning of dfsg evolve >> over time. Back to configure.ac, I'd support a choice of making a >> missing configure.ac an 'important' bug, and not enough for >> rejecting the package as non-dfsg. > > The general rule of thumb that I've followed in similar situations in > the past (PDF files where the original source has been completely > lost, for example) is that the underlying purpose of the DFSG source > provision and of free software in general is to ensure that the > recipient of the software is not at a disadvantage. In other words, > the distributor isn't allowed to hold back pieces that make it harder > for the recipient to modify the software (within the general > definition of "source," of course). > > Therefore, it matters what the distributor has. If they have the > true source used to generate the file but are keeping it secret, then > to me that's a violation of the DFSG and we shouldn't participate > (even if their actions aren't technically a violation of the license > since if they own the copyright they don't need a license). This is > creating that disadvantage for the recipient that free software is > designed to prevent. But if the original source has been lost, then > everyone is on an equal footing, and I don't think there's a DFSG > violation. We may not have the true source in the intended sense, > but *no one* has the source, and therefore everyone is on an equal > footing and has equal ability to modify the software. > > There is a different wrinkle in this specific case: we may have the > source but not the software that was used to generate the file from > the source. In this case, it sounds like an old version of Autoconf > was used, and we don't package that version of Autoconf any more, so > while the source is present in one sense, one can't regenerate the > file. I'm not sure the DFSG is the most useful framework for > analyzing that situation, since to me it feels more practical than > freedom-based. Everyone is still in basically the same situation: > the source is available to everyone, but some work may be required to > go hunt up the old tool and regenerate the file. (This assumes a > case like Autoconf where the old releases of the tool are readily > available and not kept secret, but may be hard to get working.) > > The real problem in this case is less about the DFSG and more about > the practical problems of maintaining Debian as a software > distribution: if we can't regenerate configure using software in > Debian, there are a lot of porting tasks and some bug-fixing tasks > that we can't do, and that's a problem for us. But I'm dubious that > it's a *software freedom* problem; it's more of a *software > maintenance* problem, and thus the bug severity should be based on > how much of a problem that is in practice. > > (I think this is mostly a long-winded way of saying the same thing > Marco said.) (Sorry for not snipping; I couldn't find any part that seemed more worth omitting than any other.) I tend to agree, on your parenthetical last statement. I was not persuaded by Marco's own post, but your more long-winded version has convinced me, I think. I would just like to also note two potentially-relevant questions, in making the analysis - both to do with the possibility of making changes to the file, and both of which are likely to have the same answer: * If upstream were going to change the configure process, what file would they edit? * If you wanted to make changes to the configure process and submit them to upstream for possible inclusion, which file would upstream want the patch with the changes to be against? By the "preferred form for modification" definition, whichever file that is is likely to be the one that is considered the source. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Firmware GR result - what happens next?
On 2022-10-02 at 13:52, Russ Allbery wrote: > Shengjing Zhu writes: > >> On Sun, Oct 2, 2022 at 10:53 PM Steve McIntyre >> wrote: > >>> So this is the one bit that I don't think we currently have a >>> good answer for. We've never had a specific script to run on >>> upgrades (like Ubuntu do), so this kind of potentially breaking >>> change doesn't really have an obvious place to be fixed. > >>> Obviously we'll need to mention this in the release notes for >>> bookworm. Should we maybe talk about adding an upgrade helper >>> tool? > >> For upgrading, people already need to edit their source list to >> change the suite name, why would it hurt to add one more manual >> step to change the section name? > > I think the difference is that if you don't update your sources.list > to point to the new suite, your system won't upgrade and so the > problem will be very obvious. But if you currently have non-free > configured but don't add the new firmware section, everything will > appear to work but you won't get new firmware, so the problem may go > unnoticed. There's also the issue of people who track stable or testing by that name, rather than by the release-specific codename, and so *don't* need to edit sources.list to start getting the packages from the new release. I don't know how many of us there are, but I know there's at least me (for the testing case), and I'd greatly prefer to be able to run an upgrade and have things Just Work rather than need to make sure I catch whatever notification comes along and make that change at the right time to coordinate with when the 'upstream' change is made. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: feedback for NEW packages: switch to using the BTS?
On 2022-04-29 at 08:36, Steve McIntyre wrote: > Paul Wise wrote: > >> During the discussions about NEW on debian-devel in recent times, I >> had the idea that instead of the current mechanism of sending >> REJECT mails, Debian could switch to using the BTS for most >> feedback on NEW packages. >> >> This means that most discussion about NEW packages would become >> public, but of course the ftpmasters could opt to send private mail >> instead if in some cases if there were sensitive issues to be >> discussed. >> >> The ftpmasters could simply file severity serious bug reports >> against NEW packages that have issues blocking their entry into >> Debian. When there are minor issues noticed at the same time, then >> file bugs of a lower severity. Only when a NEW package has not had >> its serious bugs fixed in a long time would an eventual removal and >> REJECT mail happen, perhaps after a few months of zero action on >> the bug reports. > > Just to clarify: is this suggesting that packages from NEW would end > up in the archive even with serious bugs? If not, what's the point > of the "eventual removal" above? I'm not following you here... I parsed that not as "removal from the archive" but as "removal from the NEW queue", much as now happens (in some order and via some mechanism, perhaps a manual one) when a REJECT mail is sent. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: shim-signed
On 2022-04-26 at 18:05, Paul Wise wrote: > On Tue, 2022-04-26 at 20:41 +0200, Bastian Blank wrote: > >> secure boot signing process at Microsoft is a review-sign process > > What kind of review are Microsoft doing of the Debian shim? > > Are they reviewing the source and checking for a reproducible build? I'd be curious to have a more in-depth answer to this, myself. My understanding has always been that they check to make sure that what they're signing is not visibly malicious, and in most cases also that it can't chain to load something else (which isn't signed, and might be malicious). Since the entire purpose of the shim - at least as I understand it - is to chain to load something else, clearly either that understanding is not correct, or they're making an exception for the case of the shim. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: shim-signed
On 2022-04-26 at 10:14, Marc Haber wrote: > On Sat, 23 Apr 2022 18:21:47 +0100, Steve McIntyre > wrote: >> Alternatively, people can build replacement shim-signed packages >> using their own root of trust if desired. If we had a large enough >> number of users wanting a different root of trust, we could even >> offer our own different shim-signed package to match. > > I would probably prefer to have grub an/or the kernel signed, > avoiding additional code, but maybe having some explanation would > convince me that the shim actually improves things additionally to > adding complexity. My understanding has always been that the point of having a Microsoft-signed shim, rather than having Microsoft sign GRUB or the kernel, is to A: avoid the need for round-trip with Microsoft's signing facilities every time the GRUB or kernel packages are updated, and B: ensure that end-users can still build their own kernels (et cetera) without having to go through the Microsoft signing process, even if their systems are set up to take advantage of the signed shim. (And the point of having Microsoft sign it, rather than using a signing key under the control of e.g. Debian, is that Microsoft's key is already considered valid by the relevant firmware environments - including the ones that can't be told to add another key to the list of valid ones. That avoids having another barrier to entry, in the form of a set of steps at the start of the install process which is going to be different per UEFI designer, and is also going to be complex and unintuitive from the perspective of a non-technical potential new user.) I can't speak to how big of an advantage A is, but B seems to me to be pretty important. If that understanding is not correct, I'd be interested to learn what the actual point of having the shim is. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: multiple roles of d/copyright
On 2022-02-10 at 09:06, Scott Kitterman wrote: > On Thursday, February 10, 2022 8:26:23 AM EST Simon McVittie wrote: >> I think the copyright file is doing several things which are perhaps in >> conflict: >> * It's a place to reproduce information that licenses require us to, like >> a comprehensive set of copyright notices (if our interpretation of the >> applicable licenses is that pointing to nearby source code and calling >> it extremely comprehensive accompanying documentation is insufficient) > How about it enables the project to comply with license requirements? I may > have missed it, but I don't see that on your list. Isn't that the above paragraph? -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Legal advice regarding the NEW queue
On 2022-02-04 at 04:00, Philip Hands wrote: > Scott Kitterman writes: > > ... >> My impression is that people are tired of waiting on New, but no >> one really seems to be interested in doing any work on any >> alternative other than more bugs. > > Part of the problem is that New processing is a bit of a black box, > so it's not clear to those of us outside the team how we could help. > > (or at least, not clear to me -- links welcome). > > As a random example, I noticed John Goerzen's post[1] about Yggdrasil > on planet.d.o last month. John has since uploaded a package. > > As I write it's still in New[2], which is no great shock, as it's > only been a couple of weeks. If I read your response (and Andrei's) correctly, you're approaching this in terms of providing copyright reviews for packages waiting in NEW, to relieve some of the burden on the FTP team and speed up the processing of those packages through NEW. What I read Scott as having been suggesting, by contrast, is that people instead do copyright review for packages already in Debian, which may well have had changes that did not have to pass through NEW and that might not have been able to pass the NEW copyright review. If a practice of doing that latter were established and sufficiently widespread, then it would not be as important to do the review for every package in NEW, and the FTP team might feel less of a need to insist that the review take place at that stage of things. > On reflection, I think that removing the bottle-neck of New would be > a mistake, as it would the remove the itch we all want to scratch. > > Instead please just provide us with the ability to scratch that itch > and you may find that you suddenly have quite a few more volunteers. I do, however, concur with these sentiments. Expanding the sphere of those who can to provide reviews (if not necessarily grant approvals) to packages in NEW might well be a good idea. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Legal advice regarding the NEW queue
On 2022-02-02 at 11:21, Michael Stone wrote: > On Wed, Feb 02, 2022 at 09:39:02AM -0600, John Goerzen wrote: > >> On Tue, Feb 01 2022, Russ Allbery wrote: >> >>> I would hate to entirely lose the quality review that we get via >>> NEW, but I wonder if we could regain many those benefits by >>> setting up some sort of peer review system for new packages that >>> is less formal and less bottlenecked on a single team than the >>> current NEW processing setup. >> >> This is a fantastic idea. >> >> In fact, it wouldn't have to bottleneck packages at all. I mean, >> if a quality issue is found in NEW, wouldn't the same be an RC bug >> preventing a transition to testing? > > I'm not sure "nobody ever looked at this" is a suitable criteria for > inclusion in a stable release. We sort of have that problem now in > crusty corners of the archive if someone uploads a bad change, but at > least there's been one review at some point in the package's > lifetime. Doesn't that, then, lead to the suggestion that any package entering unstable without having undergone NEW review (which, in the revised model, might be every new package) should automatically have a bug filed against it requesting suitable review, and that bug should be treated as a blocker for entering testing? That wouldn't help the "someone uploads a bad change" problem for already-accepted packages, but it would seem to avoid the "nobody ever looked at this" situation. It would also increase the number of automatically-filed bugs by quite a lot, I suspect, which would itself be some degree of downside... -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Do we need to hide packages in NEW queue
On 2022-01-31 at 12:32, Russ Allbery wrote: > Marc Haber writes: > >> Even if a lawyer says A, it doesn't buy us anything if J Robert DD >> gets sued and the judge says B, or "not A". > > Yes, a legal opinion cannot fully resolve the question, > unfortunately, since it's a risk judgment. Copyright law is murky > enough that it's unlikely that any lawyer will be willing to > guarantee that we won't lose a lawsuit, and of course no one can > guarantee that we won't be sued. > > What a lawyer can do is give us a better risk analysis. How *likely* > is it that we would be sued over such a thing, and if we were, what > would happen then? How much would it cost us to dispose of the > resulting lawsuit? > > I think it's useful to view this as a price. We're paying a quite > substantial price right now to implement pre-screening. If we > increase the risk that we may temporarily distribute something that > we shouldn't until we discover that and fix it, that comes with some > corresponding increased risk of a legal cost. But in the meantime > we'd be saving a substantial pre-screening cost. My understanding has been that the issue is partly that once something makes it through NEW and into the repository, it is (in principle) there forever; it'll continue to be available through various archive locations, ultimately TTBOMK cascading back to snapshot.debian.org, indefinitely. I am not on the inside of these things, certainly, but I have kept my eyes open from the outside, and I am not aware of there being any mechanism for removing something root-and-branch - across all affected versions, however far back those may stretch - from these repositories and archive locations once it's made it in. In order to avoid continuing to distribute something which we once accepted but which has since been deemed legally undistributable (and thus exposing ourselves to copyright-infringement lawsuits), we would need to have such a mechanism. (If we already do, I'd be interested to learn what it is, in terms of how it's invoked and - to the extent that this isn't unimportant implementation details - how it functions.) Even leaving aside the practicalities of that, I am on a certain conceptual and/or philosophical level uncomfortable with such a removal; having something which was once on a level of distribution to make it into snapshot.debian.org (and might be installed on my machine, or on one of my machines) be removed from that location, and thus no longer available, feels somehow wrong to me. (IOW, I appear to approve of the principle that these things remain there forever.) That could easily not be (and, in fact, probably is not) enough to outweigh the price we're facing now with the pre-screening of NEW, but it's at the very least enough that if not, that would be yet one more weight on the pile of the the reasons why copyright law is Why We Can't Have Nice Things. (I concur with your assessment and arguments overall, I just didn't see this one angle being addressed anywhere, and I feel that it's important enough - assuming it applies at all - to make sure it doesn't get overlooked.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: merged-/usr transition: debconf or not?
On 2021-11-18 at 20:06, Luca Boccassi wrote: > On Thu, 2021-11-18 at 16:23 -0500, Zack Weinberg wrote: > >> Luca Bocassi wrote: >>> [merged /usr] is the default. It has been the default for >>> multiple releases of multiple distributions. All Ubuntu >>> installations that were not using this default are now forcibly >>> converted upon upgrade to 21.10. >>> >>> And yet nobody has actually seen [the file disappearance bug] >>> happen, to the best of my knowledge. >> >> I already explained why that doesn't prove the bug is a non-issue. >> To the contrary; it means there is an enormous installed base of >> systems where the bug is latent, waiting to cause problems under >> conditions which we can reasonably expect to occur shortly after >> the release of bookworm. Please do not make me repeat myself. >> >> zw > > I'm afraid you have not. Why would the release of bookworm make any > difference? There will be nothing new that hasn't already been > happening for years. I interpret Zack's comment as referring to this, which he said in https://lists.debian.org/debian-devel/2021/11/msg00205.html: > [P]eople aren't doing the package changes that trigger the bug, yet. > They can't, because that would break systems where /usr hasn't been > merged. If the bug is not fixed I expect it will start causing > problems in unstable *after* bookworm, since (as I understand the > current transition plan) bookworm+1 development is the earliest that > package maintainers may assume /bin is a symlink. IOW, I interpret him as disagreeing with you that "there will be nothing new that hasn't already been happening for years". Specifically, I parse him as arguing that: * to date, package maintainers have not yet begun moving already-packaged files from / to /usr/ (specifically because doing so would break systems that have not yet been migrated to merged-/usr, and Debian has not yet declared that such systems are unsupported), * after bookworm, package maintainers will start moving already-packaged files from / to /usr/, and * doing this will, in a non-negligible number of cases, trigger the bug to manifest on systems where that package is upgraded from a version where the move had not taken place to one where it has. (Zack, if I've gotten any of those wrong, please don't hesitate to correct me; I'll either apologize, or drop right back out of the discussion to go hide in a metaphorical hole, if not both.) Do you dispute any of those three points? If so, I'd be interested to know which one(s), and why. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Future of /usr/bin/which in Debian?
On 2021-09-21 at 16:16, Michael Stone wrote: > On Tue, Sep 21, 2021 at 09:00:52AM +0100, Jonathan Dowland wrote: > >> On Mon, Sep 20, 2021 at 11:02:49AM -0400, Michael Stone wrote: >> >>> It seems to install to /usr/bin/which.gnu, implying that you >>> could upload /usr/bin/which.bsd if you so desire; what's the >>> issue? >> >> I think we should have just one which implementation in the >> archive. We should (have) pick(ed) the best one for Debian. I >> believe (perhaps unfairly... I'd love to be proven wrong) that the >> GNU implementation was uploaded very quickly, without the BSD >> implementation being considered. Perhaps the GNU one is the best >> fit for our needs. It would have been nice to see that there was an >> evaluation. > > I think it doesn't matter how many which implementations are in > debian. If you want something with specific portable semantics, just > use command -v. I think I've seen that suggested a lot as an alternative for 'which', but it doesn't seem to be comparably reliable in all contexts. The primary issue I've run across to date is with aliases. For example, on my computer as I type this: $ which ls /usr/bin/ls $ command -v ls alias ls='ls -N --color=auto' $ $(which ls) / bin homelib32 media pulse srv var boot initrd.img lib64 mntroot sys vmlinuz dev initrd.img.old libx32 optruntmp vmlinuz.old etc lib lost+found proc sbin usr $ $(command -v ls) / bash: alias: -N: not found bash: alias: /: not found And then 'ls' is broken in that shell session; I haven't yet found a way to get it working again, short of exiting and re-launching the shell. (Though I also haven't tried *terribly* hard.) This seems to demonstrate that you can't safely just use 'command -v' wherever you would otherwise use 'which'. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Package name misspelled in binNMU changelogs
On 2021-08-25 at 10:22, Sebastian Ramacher wrote: > On 2021-08-25 16:07:02, Tomas Pospisek wrote: >> You still can do a NMU or send a patch to the maintainer... > > Any future upload or binNMU will get rid of my typo without any > additional action. So no action is needed, this will resolve eventually in any case, as long as there's ever another update to the affected package? In that case, that entirely addresses my concern, and I apologize for the noise. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Package name misspelled in binNMU changelogs
I'm not sure if this is worth giving any attention to, but it's the sort of thing that's going to keep bothering me at a mild level if nothing is done about it, so I figure I might as well at least ask. Over the period since the release, I've seen quite a few packages show up in testing with an automated-looking changelog entry along the lines of: * Binary-only non-maintainer upload for [arch]; no source changes. * Rebuild to drop dependency on libgdk-puxbif2.0-0 This has the vowel-transposition spelling error of "puxbif" instead of "pixbuf". There are currently 70 changelog entries of that form on my computer; how many other packages might be affected I don't know. If this were a simple spelling error in the changelog wording, I'd probably just ignore it. Since it's referencing the name of another package, however, that doesn't seem quite right; at the very least, it's going to make looking for changes which reference that other package harder. If I saw a spelling error like this in the changelog for just one single package, I'd probably file a wishlist bug report against that package to request that the shipped changelog be retroactively updated to correct the error, and leave it at that. Since the number of affected packages (and, I suspect, source packages) is so sizable, however, that doesn't seem entirely reasonable; not only would that be a lot of tiny wishlist bugs, even identifying the set of affected packages isn't something I'm in a position to do without what to me is a noticeable degree of effort. Is there any reasonable way to get this spelling error corrected in the changelogs across all these packages? Or is this too minor to be worth bothering with, and something that should be just left to lie as it stands? -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: merged /usr considered harmful
On 2021-07-16 at 03:18, Marc Haber wrote: > On Fri, 16 Jul 2021 01:44:54 + (UTC), Thorsten Glaser > wrote: > >>Marc Haber dixit: >> >>>think we can afford an additional time sink at the moment. Please, get >> >>While that’s true… > > You conveniently snipped the "I don't" which turns your quote into the > opposite that I wanted to say. No, he didn't; he reordered the quoted lines (moving this one ahead of the rest), so that he could put this one line of his reply where it would make the most sense relative to the rest of his reply, without also having to adjust the within-each-line quoting etc.. The "I don't" is in the first line which you yourself didn't quote. The result was slightly confusing to me at first glance, but I figured it out within a minute. If you'd chosen to chide him for reordering lines in a way which (presumably inadvertently) produced an initially-misleading result, that would be one thing, but I don't think it's appropriate to accuse him of snipping out context when he didn't do so. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Unique kernel with my own backup of all Debian repositories
On 2021-06-12 at 12:52, Polyna-Maude Racicot-Summerside wrote: > Hi, > > On 2021-06-12 12:21 p.m., John E Petersen wrote: > >> Hey folks, I’m developing a unique kernel based on Debian Linux, >> and I’ve been scraping the website for repositories. After a few >> thousand, the servers start to block my ip. >> >> I’m just trying to keep the crazy government out of Linux, because >> they keep monkeying with repositories on Ubuntu, not to mention >> snap/snapd/brltty/systemd… > > Did you smoke something that wasn't meant to end up in your lungs ? > Have you ingested some mushrooms ? > > What you write here is a total screw-up non-sense ! I think it's mostly just a matter of mistaken terminology. There may well be faulty assumptions underlying parts of it (certainly there are things which it seems to be assuming are true that I would probably disagree about), but not nearly as much as you seem to be parsing. I interpreted the original mail as asking a question roughly along the lines of: "I'm trying to create my own Linux distribution, based on Debian, because I think a lot of the things that have been happening in Debian-derived distributions such as Ubuntu lately are the result of insane government action. However, in the course of trying to pull all existing Debian packages et cetera to create a local repository to use as the base of this distro, I can only download a few thousand items; after that, the server starts blocking my IP address, even though I'm not doing anything malicious. Why is this happening, and how can I get an appropriate replica of the appropriate repositories / et cetera, to use as the basis of such a derived distribution?" Except mistakenly using the term "kernel" instead of "distribution", and with more detail (albeit still vague and FUD-ish) about specific things which are interpreted as evidence of government-insanity meddling. Just at a glance, I'd guess that the problem is that the downloads are hammering the servers, and they're blocking the downloading IP address as an anti-DoS measure. I had a similar issue at one point for rather different reasons, and if memory serves, I avoided the issue by just adding a (possibly-semi-random) delay period - of only a few seconds - after the download of each consecutive file. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Making Debian available
On 2021-01-16 at 05:58, Andrew M.A. Cater wrote: > On Fri, Jan 15, 2021 at 03:15:14PM -0500, Theodore Ts'o wrote: > >> On Fri, Jan 15, 2021 at 09:35:01AM -0800, Russ Allbery wrote: >> >>> The point is to make things easier for our users. Right now, >>> we're doing that for you but not for the users who don't care >>> whether firmware is non-free. I think the idea is that we should >>> consider making things easier for both groups of users. There's >>> no reason to make things worse for you and others who want the >>> fully free installer in the process. >> >> I wonder if a compromise would be to make an install CD/DVD which >> contains the non-free packages, but which gives the user the option >> to abstain from using said non-free packages --- it can explain >> that the non-free packages may be needed for some hardware, but why >> people who are committed to Free Software might prefer loss of >> functionality to using non-free software. > > It already does: the second or third question gives you the option to > install non-free firmware, if needed, from a USB stick. That method > does work but very few people use it. That's not what Ted seems to be suggesting, though. It still requires you to obtain the firmware separately and provide them separately - and, per comment seen elsewhere just this morning (#980205), apparently doesn't make clear *where* and *how* to provide that firmware. What I read Ted as suggesting is that there be available an installer image which *has those files / packages already present*, but prompts the user to decide whether or not the installer should make use of them. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: On doing 3000 no-source-change source-only uploads in January 2021
On 2021-01-04 at 04:27, Adrian Bunk wrote: > On Thu, Dec 31, 2020 at 02:16:23PM +0100, Bernd Zeimetz wrote: > >> Although the high number of packages makes me wonder, if at least a >> quick MIA check of the maintainers is warranted, or - if those packages >> are needed in bullseye at all. > > Maintainership status is a very poor indicator whether users might need > a package. > > Some obscure stuff is well maintained, like m68k and Hurd being among > our architectures with the most active maintainers. > > It is very hard and high effort for people who are not already active in > Debian development to get a change into Debian or take responsibility > for a package. Debian is not a welcoming place for new contributors. > > A normal user won't even notice that an important package is missing > before bullseye is stable. As a demonstrating example of this last point: I track testing, rather than stable, and subscribe to debian-devel, and therefore am not even a "normal" user in this sense. A package I use regularly (moosic) was removed from testing back in November of 2019, and from unstable back in April of 2020. I didn't notice anything until October or November of 2020 (when the Python 3 transition tried to remove the package from my computer), and didn't realize that what I had noticed meant the package had been removed from the archive - even testing, much less unstable - until December of 2020. I've adopted it upstream (it had been abandoned by its original author back in 2011) and fixed the issues which had led to its removal, and its Debian maintainer - who hadn't noticed the removal from unstable either, until looking at it again after I provided a new upstream version - has agreed to handle the packaging again, but it's not at all clear whether it'll be ready and make it through NEW again ahead of the release freeze. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: RFC: Final update of DEP-14 on naming of git packaging branches
On 2020-09-04 at 11:42, Raphael Hertzog wrote: > So here's my counter proposal: > > --- a/web/deps/dep14.mdwn > +++ b/web/deps/dep14.mdwn > @@ -201,12 +201,16 @@ Native packages > > The above conventions mainly cater to the case where the upstream > developers and the package maintainers are not the same set of persons. > - > -When upstream is Debian (or one of its derivative), the upstream vendor > -should not use the usual `/` prefix (but all others vendors should > -do so). The main development branch does not have to be named after > -the codename of the target distribution (although you are free to still > -use the codename if you wish so). > +By contrast, this section applies to native packages where upstream is > +Debian (or one of its derivatives) and where the packaging and upstream > +source code are managed in the same branch(es). > + > +In that specific situation, the upstream vendor should not use the usual > +`/` prefix for their branches and tags (but all others vendors > +should do so) As long as this is being patched anyway, how about fixing the "others vendors" duplicate pluralization? I'd suggest either "but all other vendors should do so" or "as all others should do", but other variations are possible and I don't have a strong preference. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: RFC: Final update of DEP-14 on naming of git packaging branches
On 2020-08-31 at 06:49, Paride Legovini wrote: > Simon McVittie wrote on 30/08/2020: > >> On Sun, 30 Aug 2020 at 15:36:53 +0200, Raphael Hertzog wrote: >> >>> If I know that the next upstream release breaks backwards >>> compatitibly and that it will have to mature a long time in >>> experimental until all other packages are ready, I might start >>> to package it rigth now in debian/experimental and continue to >>> use debian/latest for my unstable uploads. >> >> If that's your workflow (the same as src:dbus, where versions >> 1.13.x are a development branch not recommended for general use), >> then I don't think debian/latest is a good name for that branch, >> and I'd recommend using debian/unstable for your unstable uploads. >> >> Rationale: it seems very confusing if a branch with "latest" in its >> name does not contain the newest available version :-) > > +1, moreover I find that "latest" does not convey the idea of > something that is in development: I tend to think about it in terms > of "latest release" or "latest version", something that is set > already. > > This is fine with uptream/latest, as we import the latest *released* > version of the upstream source, not the current work in progress > tip. I'd tend to agree with this. > Personally I'd prefer 'debian/devel': clearly the branch where > development happens. But what about cases where what would have been the 'master' branch tracks what's in e.g. sid and is being temporarily left to sit, except for bugfixes et cetera, while actual development happens somewhere else (e.g., in experimental)? Calling the replacement branch 'devel' then still gives the impression that that is where development is happening, but in such a case, that impression is misleading. The primary sense of "master" as a branch name in this context, as I understood it, was something like "the branch which everything else should be considered to be in some sense derived from"; experience seems to show that that sense allows for considerable versatility. IMO we should aim to retain that meaning in whatever name is chosen to replace 'master', for minimum disruption - and for the minimum semantic difference from that sense, IMO the closest fit I've seen yet is 'primary'. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: RFC: Final update of DEP-14 on naming of git packaging branches
On 2020-08-30 at 14:46, Richard Laager wrote: > On 8/30/20 12:02 PM, Sean Whitton wrote: > >> Hello Raphael, >> >> On Fri, 28 Aug 2020, at 4:01 PM, Raphael Hertzog wrote: >>> diff --git a/web/deps/dep14.mdwn b/web/deps/dep14.mdwn >>> index 0316fe1..beb96ea 100644 >>> --- a/web/deps/dep14.mdwn >>> +++ b/web/deps/dep14.mdwn >>> +In the interest of homogeneity and of clarity, we recommend the use of >>> +`debian/unstable` over `debian/sid` as it better conveys its special nature >>> +as opposed to other branches named after codenames which are used for >>> +stable releases. >> >> I think we should recommend debian/sid because for some years dgit >> has been generating branches called dgit/sid. I think it would >> smooth the integration between branches on salsa and branches on >> dgit.debian.org if both always used codenames. > > Using debian/sid makes the branch name inconsistent with > debian/changelog, which traditionally uses "unstable" not "sid". It > also makes debian/experimental an outlier that cannot be made > consistent (because there is no character code name for experimental > AFAIK). I thought the same at one point, but in fact, there is: it's called rc-buggy. https://wiki.debian.org/DebianReleases#Codenames http://ftp.debian.org/debian/dists/rc-buggy/ -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: RFC: Final update of DEP-14 on naming of git packaging branches
On 2020-08-30 at 10:02, Simon McVittie wrote: > Rationale: it seems very confusing if a branch with "latest" in its > name does not contain the newest available version :-) > > (debian/master didn't have that problem because it's named by > analogy to the "master" branch used in upstream git repositories, > which doesn't really have a fixed meaning anyway.) This would be the reason why I would have argued against choosing 'latest' for the name. If a replacement for 'master' is needed, the best candidate I've encountered or come up with yet is generally 'primary'. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Proposal: Allowing access to dmesg for users in group adm
On 2020-08-17 at 07:47, Bastian Blank wrote: > Hi > > On Mon, Aug 17, 2020 at 03:50:37PM +1200, Matthew Ruffell wrote: > >> 2) Following changes to /bin/dmesg permissions in package >> 'util-linux' >> - Ownership changes to root:adm >> - Permissions changed to 0750 (-rwxr-x---) > > You mean 0754? I missed this detail of the proposal. Please ignore my previous mail. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Proposal: Allowing access to dmesg for users in group adm
On 2020-08-17 at 07:42, Marco d'Itri wrote: > And what would be the point of setting kernel.dmesg_restrict=0 al long > as dmesg is still not world-executable? As far as I'm aware, it is: $ dlocate `which dmesg` util-linux: /bin/dmesg $ apt-cache policy util-linux util-linux: Installed: 2.36-2 Candidate: 2.36-2 Version table: *** 2.36-2 900 900 http://ftp.us.debian.org/debian testing/main amd64 Packages 100 /var/lib/dpkg/status 2.33.1-0.1 800 800 http://ftp.us.debian.org/debian stable/main amd64 Packages $ ls -lh `which dmesg` -rwxr-xr-x 1 root root 83K Aug 1 13:28 /bin/dmesg Is there some Debian context in which this isn't the case? -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: isc-dhcp-client sends DHCPDISCOVER *before* wpa_supplicant authenticates/associates/connects.
On 2020-07-11 at 21:56, Marco d'Itri wrote: > On Jul 11, Jonas Smedegaard wrote: > >>> (Way more people should switch from wpa_supplicant to iwd.) >> >> Difficult when network-manager depends (not recommends) wpa-supplicant: >> https://bugs.debian.org/919619 > > How to switch to iwd: > > apt install iwd > cat << END > /etc/NetworkManager/conf.d/iwd.conf > [device] > wifi.backend=iwd > END > systemctl restart NetworkManager I don't run either systemd or NetworkManager, and I'm not currently interested in changing either of those things, but I am interested in trying out an alternative to wpa_supplicant. Is there an appropriate similar procedure for such an environment, or would I have to experiment and play around trying to get things to work? I also have quite a few network definitions in wpa_supplicant.conf, and I wouldn't want to have to re-enter them manually into a new system if I could avoid it. Is there a migration procedure, other convenient way to bring those settings across into iwd? (I'm not at the computer involved at the moment, so I can't easily check things to see whether any of the answers might be quickly obvious.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: apt 2.0 release notes
On 2020-03-10 at 06:58, Julian Andres Klode wrote: > On Sat, Mar 07, 2020 at 09:41:44PM +0100, Julian Andres Klode wrote: > >> ### Incompatibilities >> >> * The apt(8) command no longer accepts regular expressions or wildcards as >> package arguments, use patterns (see New Features). > > Correction - regular expressions starting in ^ or ending in $ (that is, > anchored) are still being accepted. We know there are multiple scripts > out there using those, and they are safe to handle. > > After evaluating feedback, we'll soon be reinstating wildcards using > * as well, but no other special characters from glob(7), as most of those > seem pointless in our context, and limiting our exposure to * makes it > easier to reason about. > > So syntax overview for package arguments: > > ^foo Regular expression > foo$ Regular expression > foo* Wildcard (* may appear anywhere, and multiple times) > ~foo Pattern > ?foo Pattern > task^ Task Just for completeness / clarity, as with when this was announced previously as upcoming: What about inline install/remove markers, of the form foo+ foo- , which modify install/remove behavior on a per-package basis in 'install', 'remove', and (I think) 'upgrade' classes of invocation? My understanding from before is that while these still result in ambiguity depending on what package names exist in the available repositories, they are not being affected by the current change. Is that (still) correct? Are there any known plans for changes regarding this inline install/remove syntax in the currently foreseeable future? -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Is there still a point in installing libgcrypt to /lib instead of /usr/lib
On 2020-02-18 at 20:50, Guillem Jover wrote: > On Sun, 2020-02-16 at 11:59:56 +, Simon McVittie wrote: > >> I would be grateful if people who advocate transitioning >> individual packages, and people who consider the approach taken by >> usrmerge and debootstrap to be sufficient, could refer to their >> preferred route in a way that makes it clear which one they are >> advocating. Saying we should do a transition "properly" is >> tautologous - of course we should! - but when people disagree about >> what the proper way to do it is, it becomes an ambiguous >> recommendation that doesn't guide anyone to do the right thing. > > I've been consistently calling the concept of merging /* into /usr/* > as merged-/usr and the specific approach of using directory symlinks > as merged-/usr-via-symlinks (although I think that's confusing as > the other approach does use symlink farms), so I think using either > merged-/usr-via-aliased-dirs or merged-/usr-via-symlink-dirs is more > clear (will be renaming the buildinfo tainted tag). The approach > I've been proposing I'd call merged-/usr-via-moves-and-symlink-farms > or something along those lines. As a tangent, because this has never made sense to me: Is there a reason this is all looking to merge /* into /usr/* instead of the other way around? The latter looks to me as if it would ultimately make it possible to drop the /usr directory entirely (once we've had a release or three in which it contains nothing but symlinks) - whereas the former means we'd have the extra four characters at the head of nearly every path to installed software forever, for no apparent benefit, and would also seem to mean we'd have to keep the symlinks in / around potentially forever, even after the transition has been complete for yonks. I'm not sure I'd support dropping /usr, but I don't think I can remember having ever run across (or come up with) any arguments against it which don't seem like they would also be arguments against doing this merge at all, so the fact that the merge is apparently being done in this direction has consistently puzzled me. Does keeping /usr have some kind of benefit in its own right which I'm not seeing, even for cases when it's on the root filesystem? (Answers in the forms of pointers to Websites, or even to archives of past discussion where this would be made clear, are entirely acceptable.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Adding security features
On 2020-02-03 at 11:51, Marvin Renich wrote: > As a specific example of unnecessary default security, take the > "https everywhere" campaign. Having https available on most servers > is definitely good. However, if you explicitly go to > http://www.google.com/ you are redirected to the https version. Of > all the (hundreds of?) billions of google searches done every day, > how many of them would really cause any harm at all if the > communications were unencrypted? Yet the entire computer-using > segment of society pays the price for higher bandwidth and CPU > usage. I think part of the idea here is to promote a type of "herd immunity" against surveillance. (That analogy may be a bad one.) The more people do not use HTTPS for Google searches which aren't sensitive enough to require security, the easier it is for surveillance actors to distinguish the searches which do require it, and thereby identify targets for subjecting to surveillance - or worse - by other methods. I understand that benefit - of making it easier for those who do need the security to hide among the crowd - to be one of the major arguments for having HTTPS be used everywhere and in all cases, even places and cases which would not otherwise see any benefit from using it. That argument does not necessarily generalize to other "higher security by default" discussions, however, and at a glance I don't think I see how it would apply to the one at hand in this thread. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Deprecating regex/fnmatch fallback for package arguments, and 1.9.6 highlights
On 2020-01-15 at 17:11, Julian Andres Klode wrote: > Starting with APT 2.0 (1.9.6 in experimental), the apt(8) binary will > not try to interpret package names passed on the command-line as regular > expressions or fnmatch() style patterns. Future versions of apt-get(8) > and apt-cache(8) will follow that change, following the release of bullseye. > > # The problem > > Interpreting arguments as package name, regular expression, or fnmatch > expression, depending on which matches first, made apt very unpredictable: > > The expression `apt install g++` could mean one of > > - Install the package g++ > > - If g++ does not exist, install all packages containing g - as + is the > one-or-more operator > > Hence before 1.9.6, `apt install x++` installed any package containing x, > whereas `apt install g++` installed g++. > > This caused problems when a package with a special character such as + > or * was removed from the archive, but still used in scripts, as they > suddenly would install different packages or fail weirdly. > > # The solution > > APT 2.0 introduces patterns, as specified in apt-patterns(5), replicating > most of the the pattern mechanism of aptitude, albeit currently with only > the long-form syntax being supported. > > To support existing users, regular expressions that start with ^ or end > with $ continue to be supported. This will mainly be important once that > change propagates to apt-get and apt-cache. They might cause deprecation > warnings in future versions though, but should be around longer than just > any regular expression. > > # Overview of supported arguments > > The accepted syntax for package names in apt(8) is henceforth: > > - Patterns: Expressions starting with ?, such as ?name(^apt) > - Literal names: Any package name that exists in the cache > - Tasks: Expressions ending in ^, such as gnome-desktop^ > - Regular expressions starting with ^ or ending with $ > > All of these can still have /release or =version appended > to them. Currently, there is another syntax related to the use of + at the end of package names on the apt command line. At the moment, these two commands both do the same thing: apt-get remove package1 package2+ apt-get install package1- package2 Specifically, both commands will install package2 and remove package1. This syntax is convenient and intuitive for nearly all cases, but like the behavior you describe, means that the result of a given command technically depends on what packages are available in the current known archive. For example, if someone ever uploaded a package named 'g+' into some archive, I don't actually know what 'apt-get remove g++' would wind up doing on a system with that archive configured as available. Will this change have any effect on the ability to use that syntax? If so, what will the resulting behavior be like, and what syntax will we be able to use to achieve similar "mix and match install and remove in the same command line" results (preferably with similar levels of convenience)? -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: opentmpfiles & opensysusers, and its use in the Debian policy
On 2020-01-04 at 05:57, Simon McVittie wrote: > On Fri, 03 Jan 2020 at 19:52:33 -0500, The Wanderer wrote: > >> On 2020-01-03 at 19:33, Simon McVittie wrote: >> >>> D-Bus activation is a D-Bus feature where instead of starting a >>> D-Bus service (another sort of daemon) "eagerly" in case it might >>> be needed, the dbus-daemon starts that D-Bus service "lazily" the >>> first time some other program sends a message to it. >> >> This sounds like the feature I was thinking of. I think I >> understood that the way this message got from the originating >> program to D-Bus (and thence to the service, once running) was by >> way of a socket which would / should be owned by that service, much >> as you describe for systemd's socket-activation feature > > No, part of the purpose of the "message bus" part of D-Bus is that it > provides a hub-and-spoke topology so that connecting n clients and > services together only requires O(n) connections, not O(n**2). > Clients connect to a socket owned by the message bus service, and > send messages through it. Some messages are processed by the message > bus itself. The rest have a header that tells the message bus which > service is the intended destination, and it either: delivers the > message to the destination service immediately; activates (starts) > the destination service (via either traditional or systemd > activation), and then delivers the message when it appears; or > replies with an error message that means "no, I can't do that" (for > example if the requested service isn't installed). That actually sounds even more like how I originally thought this feature worked, and the name "D-Bus socket activation" makes even more intuitive sense in my mind for the "lazy" activation of services by this method. Still, if that's not what the terminology has been established to mean, then there's no point in belaboring the issue. I certainly have enough of an aversion for unnecessary and unintended ambiguity that I'm not interested in introducing more without good cause. Once again, thanks for the explanation! -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: opentmpfiles & opensysusers, and its use in the Debian policy
On 2020-01-03 at 19:33, Simon McVittie wrote: > On Fri, 03 Jan 2020 at 18:07:36 -0500, The Wanderer wrote: > >> What I'm concerned about is dbus socket activation, or similar, >> leading to e.g. logind getting activated by logging in at the text >> console. >> >> I thought I understood that socket activation via dbus was one of >> the features which didn't require systemd as PID-1 to function. > > I think you're confused. I don't think "socket activation via dbus" > has ever been a thing that existed. I will certainly take your word for that. That it was a thing is an understanding I acquired over the course of reading previous mailing-list discussions (both contentious and otherwise), and in examining the idea more closely over the course of this conversation I've begun to notice some things that don't seem quite right about it anyway. > Socket activation is a systemd feature resembling inetd Thanks for the explanation. > D-Bus activation is a D-Bus feature where instead of starting a > D-Bus service (another sort of daemon) "eagerly" in case it might be > needed, the dbus-daemon starts that D-Bus service "lazily" the first > time some other program sends a message to it. This sounds like the feature I was thinking of. I think I understood that the way this message got from the originating program to D-Bus (and thence to the service, once running) was by way of a socket which would / should be owned by that service, much as you describe for systemd's socket-activation feature, and that automatic "lazy" activation of the service by D-Bus in this way was therefore called D-Bus socket activation. This may itself be based on some confused understandings of some of the terms involved. If so, please don't feel obliged to spend your time explaining them; although I'd be glad to learn, I'm sure you have more productive things to do. > Some of systemd's smaller daemons, like logind, are activatable > D-Bus services, so in principle they could be started by dbus-daemon > via traditional activation. However, the "program to execute" in the > D-Bus service definition is set to /bin/false, so they cannot > actually be activated successfully unless dbus-daemon was told to > carry out systemd activation, which only happens on systems where > systemd is pid 1. That clarifies much. Thank you for the explanation! >> it also appears to leave systemd-the-package as much less useful to >> install without systemd-sysv > > The systemd binary package is useful for systemd-tmpfiles, > systemd-sysusers, controlling a container or > system-image-under-construction that *does* boot with systemd > (systemctl --root=/mnt/otherdevice), or booting with > init=/bin/systemd as a non-default option. Other than that, you're > correct to say that systemd-sysv is the package that actually > provides services (pid 1, logind, journald, etc.). All of these (except the system-image-under-construction) are part of what I had in mind when saying "much less useful" rather than "useless". Thanks for listing them, though! >> (I wonder if maybe I had libpam-systemd installed at the time, and >> that was what was triggering logind to run? It's possible that this >> may have been back before that couldn't be installed without >> systemd-sysv > > I suspect you were using libpam-systemd in combination with > systemd-shim. The entire point of systemd-shim was that it would run > systemd-logind on systems that did not have systemd as pid 1. This > turned out to be unsupportable and it was removed. That sounds right, yes. I was surprised to find out just how much that I'd thought would grow dependencies on systemd-logind, and hence become unusable without the behavior changes which come along with logind, did not actually do so. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: opentmpfiles & opensysusers, and its use in the Debian policy
On 2020-01-03 at 17:43, Russ Allbery wrote: > The Wanderer writes: > >> If I recall and understand correctly, installing >> systemd-the-package will result in at least some of the daemons >> therein - including both systemd itself, and systemd-logind - being >> set up to run automatically in the correct contexts (whether by >> scripted invocation set up by a package, or by socket activation, >> or by some other means), in such a way that they will generally >> wind up running even on a computer where systemd-the-daemon is not >> the init system. I'm currently digging through the result of >> 'apt-get source systemd', and I haven't yet managed to either >> confirm or refute this with certainty. > > This is the bit that I'm fairly sure is not the case. > > All of the native systemd facilities are started via systemd units. > If systemd is not running as PID 1, nothing is going to load or act > on the systemd units. Therefore, nothing will start those services. What I'm concerned about is dbus socket activation, or similar, leading to e.g. logind getting activated by logging in at the text console. I thought I understood that socket activation via dbus was one of the features which didn't require systemd as PID-1 to function. > This may be a concern in some future in which there are multiple > init systems that interpret and act on systemd units, but this is not > yet the case. That will be an integration worry that we'll have to > tackle should that be the case in the future, but I don't think it's > a concern right now. That does ease my mind about this somewhat, then. It also leaves me confused about how these daemons were getting started back when I was experimenting with this, to provide the side effects which I (half-)remember seeing, since I definitely wasn't running systemd as the init system; it also appears to leave systemd-the-package as much less useful to install without systemd-sysv. But my confusion about the past should not impede us acting in the present with regard to the future. (I wonder if maybe I had libpam-systemd installed at the time, and that was what was triggering logind to run? It's possible that this may have been back before that couldn't be installed without systemd-sysv, and before I wound up giving up and removing it.) >> Again if I recall correctly, there were some behaviors which arose >> from having logind running in a non-systemd-as-init-system >> environment which the maintainers did not consider something which >> they would need to fix but which I found undesirable. > > Possibly you're thinking of the problem that Sam pointed out, which > is that the systemd package depends on libsystemd0 which currently > effectively conflicts with elogind, and therefore you can't install > elogind and the systemd package simultaneously? No - at the point when I was experimenting with this, elogind did not appear to have been packaged for Debian, and may (for all I know) not even have been written yet. >> I don't want to "risk" (in quotation marks because there may not >> be much, if any, actual risk involved) my primary system on testing >> this, and right now I don't have any spare systems or a working >> virtualization environment (because I haven't been able to get >> libvirt, as packaged for Debian, to work properly in a non-systemd >> environment) to use for testing, so I'm not in a position to do >> that test myself. I do have a functioning virtualization >> environment at my workplace, so if downtime permits over the next >> week or three, I may be able to do that there. > > Totally understood, and obviously you're under no obligation to do > the testing! No, but if it would help resolve concerns (including my own) and potentially help clear the way for things to move forward, I'd be happier with it done - and if I can make myself happy, why shouldn't I? ^_^ >> (Personally, I'd argue that splitting the various daemons and >> non-daemon tools out into packages according to which ones depend >> on which others makes sense purely from a "granularity of >> dependencies" perspective, but it's been clear for a long time that >> that argument is a nonstarter with the systemd maintainers.) > > The systemd maintainers do split out some binaries, but I don't > think creating 20-odd packages for each individual small service > (systemd has a general model of breaking the boot up into small, > simple binaries that do a single thing) is necessarily an > improvement. My understanding of the preference of the systemd > maintainers is to not split the package except where
Re: opentmpfiles & opensysusers, and its use in the Debian policy
(Here's another one I may later wind up regretting; I'm out on too many if-I-remember and if-I-understand limbs, and am thus speaking based on too many possibly-false premises, and I'm also now explaining personal preferences which might readily be deemed too minor or too niche to be reasonable to bother supporting. I don't want to just drop the conversation midstream at this point, however.) On 2020-01-03 at 14:36, Russ Allbery wrote: > The Wanderer writes: > >> On 2020-01-03 at 13:35, Russ Allbery wrote: >>> Why would that be necessary? > >> Which part? The splitting out, or the accepting of the init >> scripts? > > Both. > >> The splitting out I think I've already addressed, if not directly >> or at length; I can go over it more specifically if desired, >> although I sometimes have a hard time phrasing things in that >> context in ways which aren't unintentionally provocative. The short >> version would be: to avoid undesirable side effects from other >> parts of the systemd package. (Again, it's been long enough that I >> forget what those side effects were, although I think they had to >> do with logind.) > > So far as I can tell, installing the systemd package by itself > shouldn't do anything. It's possible that I'm wrong, but if so, it > might be easier to just fix that problem rather than splitting out > binaries. It's also possible that you ran into some long-ago-fixed > bug and there is no longer any problem with installing the systemd > package on a system that isn't running systemd. If I recall and understand correctly, installing systemd-the-package will result in at least some of the daemons therein - including both systemd itself, and systemd-logind - being set up to run automatically in the correct contexts (whether by scripted invocation set up by a package, or by socket activation, or by some other means), in such a way that they will generally wind up running even on a computer where systemd-the-daemon is not the init system. I'm currently digging through the result of 'apt-get source systemd', and I haven't yet managed to either confirm or refute this with certainty. If that's not true - if having that package installed will (now) never lead those daemons to be run without something external to the package which triggers them to get run, and a non-systemd-as-init-system machine will (now) not involve anything which triggers running them unless the sysadmin specifically sets it up that way - then I'm on entirely the wrong track here, and unless there's something else I'm not remembering, my split-the-package objections almost certainly disappear. (Although it would probably then become harder to ensure that I don't install something which is going to trigger running any of them.) Again if I recall correctly, there were some behaviors which arose from having logind running in a non-systemd-as-init-system environment which the maintainers did not consider something which they would need to fix but which I found undesirable. Unfortunately, I have largely forgotten what they were; I have a vague memory of something about normal-operation status text stepping all over the text console at which I log in and from which I startx, and that it may have been related to the fact that I was using systemd-shim rather than systemd-the-init-system and so the setup was considered unsupported by the systemd maintainers, but I'm not even certain that that was the same problem. (Of course, systemd-shim isn't even an option anymore.) I thus want to avoid letting logind run, and as far as I can tell, doing that without breaking other things means not letting systemd-the-package get installed - because even if I disable logind post-install by some mechanism, other things may have chosen to depend on systemd-the-package because they need logind, and may quite reasonably assume that the presence of the former means that the latter will be available for them to use. Given those experiences, I also have reservations about letting any other systemd-related daemons run without specific reason, just because I don't know what side effects they might cause - now or in the future. It's not as nearly absolute an objection, but as indicated in my first message, I don't trust systemd-the-project not to introduce behaviors which I find undesirable. > I don't think there's enough information on this thread to indicate > that there's any need to split out the package. Probably it would > make sense for someone to just try installing that package on a > non-systemd system and running systemd-tmpfiles and systemd-sysusers > and see if anything breaks. Given what Andrej Shadura wrote in reply to me this morning, I'd be su
Re: opentmpfiles & opensysusers, and its use in the Debian policy
On 2020-01-03 at 13:35, Russ Allbery wrote: > The Wanderer writes: > >> Unless my understanding of the architecture of >> systemd-the-init-system is entirely incorrect, running these >> .service'es is handled by /bin/systemd. If having these programs >> run at boot time is considered essential to full functionality of >> these facilities - and I'd be surprised if it wasn't - then >> something is going to have to be done to permit that to happen >> under other init systems. > > So create a package with init scripts (or runit scripts, or OpenRC > scripts) that run those binaries, and make that package depend on > systemd (*not* systemd-sysv). > > This seems fairly simple to me. Am I missing something (beyond the > fact that this is problematic on the Hurd and kFreeBSD)? Not as far as I can tell; the idea just hadn't occurred to me. >> If the maintainers of systemd-the-package would be willing to not >> only split out these binaries into standalone package(s), but >> accept such init scripts for inclusion in those packages, > > Why would that be necessary? Which part? The splitting out, or the accepting of the init scripts? The splitting out I think I've already addressed, if not directly or at length; I can go over it more specifically if desired, although I sometimes have a hard time phrasing things in that context in ways which aren't unintentionally provocative. The short version would be: to avoid undesirable side effects from other parts of the systemd package. (Again, it's been long enough that I forget what those side effects were, although I think they had to do with logind.) The accepting of init scripts seemed to me like an essential piece of making sure those scripts would be present wherever they would be needed. Your suggestion above seems to provide a way to make it less essential, and thus would make moving forward easier and more practical. The only question is how to make sure that that other package would be present whenever a non-systemd init system is in use, and that seems like a simple matter of adding dependencies from the set-foo-as-active-init-system package for foo. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: opentmpfiles & opensysusers, and its use in the Debian policy
On 2020-01-03 at 09:13, Ansgar wrote: > The Wanderer writes: > >> However, as it remains the case that they are shipped in the same >> package as /bin/systemd, and as I gather (mostly from this thread, >> I think) that some of the ways they are expected to be invoked >> probably rely on having systemd-the-daemon running > > They don't rely on the `/bin/systemd` binary at all, and I'm fairly > certain that this was mentioned in the thread (and previous) and not > the opposite. > > There was something about dh_installsystemd currently only running > systemd-tmpfiles in maintainer scripts if systemd run, but that can > be changed should Debian choose to use tmpfiles for more generic > purposes. It was Simon McVittie's message from half-past-noon (EST) yesterday, citing the various ways in which these facilities are invoked automatically on a systemd-as-PID1 system, that I was thinking of. Specifically, this part: >>> - run systemd-tmpfiles during boot (this is systemd-tmpfiles-setup.service, >>> part of systemd) >>> >>> - run systemd-sysusers during boot (this is >>> systemd-sysusers.service, part of systemd) Unless my understanding of the architecture of systemd-the-init-system is entirely incorrect, running these .service'es is handled by /bin/systemd. If having these programs run at boot time is considered essential to full functionality of these facilities - and I'd be surprised if it wasn't - then something is going to have to be done to permit that to happen under other init systems. That is, of course, equally true for any non-systemd implementations of these same facilities; as Simon also indicated, LSB init scripts or similar to invoke these facilities at boot time will be needed for opentmpfiles and opensysusers. If the maintainers of systemd-the-package would be willing to not only split out these binaries into standalone package(s), but accept such init scripts for inclusion in those packages, then I think that should entirely eliminate this particular concern; it should then be possible for other packages to depend on these facilities directly, without side effects for non-systemd environments. However, I don't see any particular reason to expect that to be the case, and certainly if it is not raised as a thing to be requested it is less likely to happen. Using opentmpfiles and opensysusers would make it possible to include those init scripts only in those packages, and avoid needing to have them on systemd-as-PID1 computers where they will never be used. That's not a major advantage, any more than avoiding .service files et cetera on computers without systemd is, but may not be of negligible weight either. >> this does not entirely obviate my concerns related to needing to >> have systemd-the-package's daemons present in order to gain access >> to these facilities. > > I'm happy to have helped overcome these concerns. Unfortunately, due to the above, the concerns remain. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: opentmpfiles & opensysusers, and its use in the Debian policy
On 2020-01-03 at 07:50, Ansgar wrote: > The Wanderer writes: > >> On 2020-01-02 at 08:14, Thomas Goirand wrote: >> >>> As I wrote, no need to complain, but act. >>> >>> https://salsa.debian.org/debian/opentmpfiles >> >> For me (with no salsa account, therefore not logged in; I don't >> know if that makes any difference), this page states "The >> repository for this project is empty". > > The repository has only tags, but no branches. This seems to confuse > GitLab's web interface, but one can still clone the repository and > checkout tags. (Probably Thomas forgot to push the branches to > GitLab.) > > Alternatively the upstream repository without the Debian packaging > bits can be found at [1] (might be a mirror, not sure). > > Ansgar > > [1]: https://github.com/OpenRC/opentmpfiles Thanks for the explanation! -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: opentmpfiles & opensysusers, and its use in the Debian policy
On 2020-01-03 at 08:50, Andrej Shadura wrote: > Hi, > > On Fri, 3 Jan 2020 at 14:02, The Wanderer > wrote: > >> On 2020-01-02 at 09:03, Sam Hartman wrote: >> >>> My understanding is that systemd's implementation of tmpfiles >>> and sysusers works even while systemd is not pid 1. Why do we >>> need multiple implementations for Debian ports where systemd >>> runs? >> >> There are those who don't run systemd-the-daemon even as non-PID-1; >> I'm one of them. >> >> In my case, this is partly due to half-remembered >> negative-impression behavior changes seen from even non-PID-1 >> systemd, back when I experimented with it around the time of the >> default transition - but I can't remember those changes clearly >> enough to specify, and it's possible that even if they did exist >> back then they might no longer be present today. (For what it's >> worth, my recollection is that they were related to logind.) > > I believe there’s significant misunderstanding here. > > Unless I’m mistaken, systemd-tmpfiles and systemd-sysusers not only > don’t require systemd to run as PID 1, but they don’t require > systemd to run at all. In fact, they don’t seem to require the > /bin/systemd binary to be installed. They do use libsystemd-shared.so > because they need e.g. bits of the string manipulation library, but > that’s it. I am not particularly surprised by this, and am pleased to learn that it is the case. However, as it remains the case that they are shipped in the same package as /bin/systemd, and as I gather (mostly from this thread, I think) that some of the ways they are expected to be invoked probably rely on having systemd-the-daemon running, this does not entirely obviate my concerns related to needing to have systemd-the-package's daemons present in order to gain access to these facilities. If these two programs were to be split out into one or more separate packages (which IMO would probably also be a good idea for some of the other binaries shipped in systemd-the-package, but that's another discussion), and those packages did not depend on the systemd package, that would greatly improve the situation from my perspective. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: opentmpfiles & opensysusers, and its use in the Debian policy
On 2020-01-02 at 09:03, Sam Hartman wrote: > My understanding is that systemd's implementation of tmpfiles and > sysusers works even while systemd is not pid 1. Why do we need > multiple implementations for Debian ports where systemd runs? There are those who don't run systemd-the-daemon even as non-PID-1; I'm one of them. In my case, this is partly due to half-remembered negative-impression behavior changes seen from even non-PID-1 systemd, back when I experimented with it around the time of the default transition - but I can't remember those changes clearly enough to specify, and it's possible that even if they did exist back then they might no longer be present today. (For what it's worth, my recollection is that they were related to logind.) But it's also partly due to a philosophical objection to the way systemd implements so many things all in more-or-less one place, and to distrust that systemd-the-daemon (and/or the package) won't later grow behaviors which I find undesirable, but which are enabled by virtue of having systemd-the-daemon running at all. I don't go so far as to prohibit even libsystemd0 (never mind udev) from being installed, although I understand that some people do - but I simply do not trust systemd-the-project not to bring undesirable changes, and consequently I want to have as little running systemd code on my system as I can reasonably get away with. If it were possible to install and make use of systemd-the-suite's implementations of tmpfiles and sysusers without needing to pull in systemd-the-daemon - or, perhaps even more importantly, the *ten* other apparent daemons which I see in a quick look at systemd-the-package - I might well be OK with that. But from my understanding, it is not, and certainly they are not packaged separately in Debian. If there were no sufficient separate / independent / standalone implementations of tmpfiles or sysusers, and packages which I can't do without grew dependencies on those facilities, I'd probably (at least temporarily) grit my teeth and bear with having to have systemd-the-package and its daemons installed and active - and who knows, maybe I'd even discover that the undesirable behaviors I half-remember don't exist anymore. But as there apparently *are* such implementations, I would greatly prefer to have the option to make use of them instead. A refusal to permit these alternate implementations to be available as alternatives, for reasons other than technical limitations of one sort or another, would seem to me like an attempt to shove systemd down my throat - and would be that much more reason for me to finally give up on Debian and try alternatives, whether Devuan or Gentoo or something farther afield. In that context, I find the entire premise of "why do we need multiple implementations of this?" to be unfortunate; "need" is, IMO, the wrong standard to use for this. -- The Wanderer (who will, as usual, probably regret posting this) The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: opentmpfiles & opensysusers, and its use in the Debian policy
On 2020-01-02 at 08:14, Thomas Goirand wrote: > As I wrote, no need to complain, but act. > > https://salsa.debian.org/debian/opentmpfiles For me (with no salsa account, therefore not logged in; I don't know if that makes any difference), this page states "The repository for this project is empty". My default interpretation would be that maybe opentmpfiles doesn't exist yet, and you just created the repo to be a place where people could get started writing it. However, other people's comments seem to indicate that opentmpfiles does exist (and is used in other distros), so that doesn't fit. Any idea what's going on here? > https://salsa.debian.org/debian/opensysusers This one shows the repository and its contents, however. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Q: what's the blocker for firefox-esr update migrates to testing
On 2019-10-31 at 10:25, Hideki Yamane wrote: > Hi, > > firefox-esr package doesn't migrate to testing but I cannot > find the reason at https://qa.debian.org/excuses.php?package=firefox-esr > > Could someone tell me why, please? Quoted from that page: >> Issues preventing migration: >> firefox-esr unsatisfiable Build-Depends(-Arch) on armel: nodejs (>= 8.11) >> missing build on armel That seems clear enough to me, although I haven't looked into the reasons why that dependency can't currently be satisfied on that architecture. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)
On 2019-08-07 at 16:59, Andrei POPESCU wrote: > On Mi, 07 aug 19, 09:28:12, The Wanderer wrote: > >> I've begun to wonder whether it might be worth the overhead to set up >> some type of mechanism to let packages which define such >> machine-specific IDs A: declare the fact, in a central location which > > Do you mean /etc? :) It would probably go under /etc/, but that's not what you seem to mean. >> the sysadmin of a machine where that package is installed can easily >> check, and B: define an automated way of performing the appropriate >> update / regenerate step in a way which covers all known places where >> the ID needs to be updated. > > 1. Delete the contents of /etc (all of it) > 2. If a package doesn't find its "stuff" in /etc it regenerates it from > defaults. > > http://0pointer.net/blog/projects/stateless.html Maybe I'm missing something, but I don't think that seems to cover all cases. For example, in the case where defining (I think it was) an mdadm array embeds the then-existing hostname into the array definition, such that the array will only be auto-assembled when it is detected on a machine with that same hostname, it's not enough to simply wipe /etc/hostname; you also need to arrange for the new hostname, once generated, to be inserted into the definition of the existing array. That's probably more relevant to the case of changing the hostname of a single machine than of cloning a machine, since I'm hard pressed to think of a plausible case for using RAID on a machine which is to be cloned (and also since I think it's possible to explicitly omit the hostname when creating the array, such that the array will auto-assemble on any system), but there's no guarantee it's the only example of something which needs to be updated outside of /etc/ in order for things to keep working. At a glance, there are also unique LVM IDs in /boot/grub/grub.cfg, though whether those would need to be changed when cloning I don't know. I also vaguely recall having once run into issues related to filesystems being by default configured to mount by unique ID rather than by device path, which thus didn't mount anymore once the filesystem had been cloned from its original drive onto a different drive which had a different ID, but it's been too long for me to dredge up any specifics. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Generating new IDs for cloning (was Re: duplicate popularity-contest ID)
On 2019-08-07 at 04:26, Russell Stuart wrote: > On Wed, 2019-08-07 at 09:34 +0200, Marc Haber wrote: > >> I am using Debian for two decades now, and I realized that >> necessity two days ago. > > Ditto - except for me it was a few seconds ago. In my case, it was when I read this thread last night. (After more like ~1.5 decades of Debian, for what that's worth.) This isn't the first time I've discovered that some aspect of a Debian system would actually need to be cleared and re-generated when that system is cloned, well after the point where it would have been easy for me to address that need. (Fortunately, although I've moved in the direction of cloned Debian systems multiple times in the past, so far all of those have petered out before reaching production. I still want to change that at some point, however.) Cloning isn't the only example of a case where some machine-specific configuration detail may need to be updated, without that being obvious in advance. I've been bitten by attempting to change the name of a computer running off of LVM on mdraid, and discovering that the hostname entered during the original install process when those two things were configured had actually been encoded into the definition of one of the two, such that the machine could no longer automatically find its filesystems at boot until some action to update the hostname in that definition was taken; the original hostname was effectively a critical ID for that filesystem. (I *still* haven't been able to pin down with certainty what action would do that update safely.) Since cloning a machine often involves specifying a new hostname for the clone, I'd expect to encounter the same issue there - although it's probably not all that common to want to clone a machine running from RAID, so if the mdraid is where the hostname is needed, the issue may not tend to come up in that context. I wouldn't be even slightly surprised if there were other examples, as well, somewhere in the package ecosystem. I've begun to wonder whether it might be worth the overhead to set up some type of mechanism to let packages which define such machine-specific IDs A: declare the fact, in a central location which the sysadmin of a machine where that package is installed can easily check, and B: define an automated way of performing the appropriate update / regenerate step in a way which covers all known places where the ID needs to be updated. Maybe a mechanism vaguely similar to /etc/init.d/ | /etc/rc*.d/ ? Say, one directory (name bikeshedding welcome) to contain package-installed scripts which will generate and apply the new GUID (or replace an existing ID with a specified new one in all relevant places, for cases such as the hostname one given above), and another directory to contain symlinks to scripts in the first directory. Then either a flag file to tell the system to run the symlinked scripts (and clear the flag) on the next boot, or just let the presence of any such symlinks be the flag indicating to run that script and remove the symlink at boot time. That way, rather than needing to research to find out what elements of the installed system need to be updated at clone time, the sysadmin could just check the relevant directory, run any scripts whose effects need to be applied pre-clone (if any), create appropriate symlinks for whichever others the sysadmin wants to have run in this case, create the flag file if applicable, shut down, and clone. ...this would be arguably reminiscent of the Sysprep tool on the Windows side of things, although probably all of more general, more flexible, and less heavy-weight. I'm sad at there being any need for such a thing in the Linux world, but as long as there are machine-specific IDs which need to be updated for effective cloning, I'd rather have such a mechanism than need to do all the work (or do the research, and write the necessary automation scripts) myself in every case. I'm not particularly attached to that exact solution; it's just the first one I came up with that seemed as if it could work with sufficient generality. If people think the idea is worth pursuing but that solution is not ideal, I would be more than happy to defer to those with more expertise. -- The Wanderer (will, statistically, probably regret posting this) The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Proposition: Insert Mozilla Firefox Release in Debian
On 2019-07-14 at 22:03, Paul Wise wrote: > On Sun, Jul 14, 2019 at 9:57 PM wrote: > >> Please Insert Mozilla Firefox Release in Debian. > > Mozilla Firefox is available in Debian, the package name is > firefox-esr. That's the ESR version. I read this as being a request to include the "release" version, i.e., mainline non-ESR. My understanding is that that's a nonstarter for one reason and another, but I don't recall all the specifics involved. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Apt-secure and upgrading to bullseye
On 2019-07-10 at 15:03, Neil McGovern wrote: > On Wed, Jul 10, 2019 at 07:51:18PM +0100, Julian Gilbey wrote: >> But I realised later that this is going to bite all users when they >> come to upgrade from buster. Perhaps some aptitude and apt-get >> patches can go into a stable (buster) point release, so that fewer >> users are hurt by this in 2-3 years' time? It is quite a >> showstopper! > > Given the release notes tell people to use "apt update", I'd be > interested to know if there was any documentation you read or > followed during the upgrade. If you didn't use the release notes, is > there a reason why? Could a tl;dr version make you more likely to > read them? For myself, no, a shorter/simplified version of the release notes probably wouldn't have made me more likely to read them. I track testing by that name (and have done so for well over a decade), and dist-upgrade on at least a weekly basis, so I never actually upgrade to a new release; I just start pulling from the new testing when the old one moves out from under my feet to become stable. Since I'm not upgrading to a new release, but just sticking with testing as I've been doing all along, I wouldn't think to check release notes. That's especially true just after the release of a new stable; at that point, it's intuitively obvious that testing can't have release notes, because until new package versions migrate from unstable the new testing is *empty*. (Whether this intuition is accurate or not.) As Julian apparently did, I only found the solution for this by a Google search for the error message I was seeing - in my case, in what I recall as being a months-old bug report, since it it hadn't been brought up post-release on e.g. debian-user yet by then. The release notes might be a valid place to document this for people upgrading from oldstable-buster to stable-bullseye after the release of bullseye, or even (if this would be applicable) switching from stable to testing-bullseye midway through the release cycle; it's considerably more reasonable to expect people to think to check release notes before upgrading at those stages. But for people who are merely sticking with testing, after the buster release just as after previous releases, the release notes are IMO not an appropriate answer. Also: I would have tried to reject a "just use 'apt update'" solution, as you say the release notes propose, and kept searching for a way to do it using apt-get - since that's my preferred client, and the idea of switching clients just for a single task like this strikes me as intuitively wrong somehow. In fact, it's possible that I *did* do that; I remember skipping multiple search results which suggested only that solution, and it's even possible that the release notes were one of them. I'd have given in eventually if no "native" solution were to be found, but since in this case one *does* exist, IMO it's not appropriate to present only the solution which would require me to temporarily switch clients. David Kalnischkies presented three different solutions, suitable for different clients, earlier in this thread. IMO, if the release notes need to document any of them, they should document all - or, if it's considered more reasonable to restrict the release notes to discussing one single recommended client, there should be another document somewhere which lists not only all of these solutions but (for discoverability's sake) as many of the client-specific error messages as may be practical. (For those clients which don't present the solution themselves, of course.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Upcoming Qt switch to OpenGL ES on arm64
On 2018-11-24 at 10:21, Simon McVittie wrote: > On Sat, 24 Nov 2018 at 15:10:47 +0100, Adam Borowski wrote: > >> I don't have access to any non-embedded Intel cards > > Do those exist? I thought Intel only made GPUs that are integrated > into their CPUs (the "HD Graphics" series). Presumably that's what > you meant when you said embedded? I don't know of any which exist currently, but a naive Google search for 'discrete Intel GPU' turns up news articles from this past August reporting that they've teased one coming out in ~2020. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: no{thing} build profiles
On 2018-10-26 at 00:51, Russ Allbery wrote: > The Wanderer writes: > >> On 2018-10-25 at 20:00, Russ Allbery wrote: > >>> The Depends field should be used if the depended-on package is >>> required for the depending package to provide a significant >>> amount of functionality. > >> This does not actually seem to conflict with the "would be found >> together in all but unusual installations" definition for >> Recommends; in a case where the depending package can still provide >> meaningful functionality without the depended-on package, but will >> miss "a significant amount of functionality" if the latter package >> is not present, both definitions would seem equally applicable. > > I don't know why you would expect otherwise? That seems entirely > natural and expected given that Depends is a stronger relationship > than Recommends, and therefore is naturally a subset of the things > that would qualify as Recommends. I think I was expecting that, since both definitions say "should", and "should" is a statement of what the right thing to do is, and you cannot do both things, the definitions would necessarily point to only one option as the one which you "should" do. (The distinction vs. "must" is that "must" is a statement of what the *required* thing to do is; with "should" the maintainer's decision can override, with "must" it cannot. In both cases, the only-one principle would apply.) Since "you should do both" is not an option, it seems inappropriate to my mind's eye for the Venn diagram of the recommendations to have any overlap; any place where one would otherwise overlap the other needs to be accounted for, and carved out of one of the two. Otherwise, no recommendation is actually being provided. > You choose the strongest relationship that is applicable. I'm not sure that's clear from the given definitions, nor that it should necessarily hold. Is there any statement which would make that explicit? I haven't noticed one in a quick look through Policy 7.2, but it's entirely possible that I've just missed it. Consider a case like "Package A's significant functions are X, Y, and Z. In order to do Z, package A needs package B. However, there are unusual cases where someone might reasonably not care about being able to do Z, but still want to do X and Y.". In that situation, both definitions apply, and the definition you cited states that Depends should be used, but the definition of Recommends states that Recommends should be used. Although Depends is the stronger relationship, it's not clear that Recommends is not the better choice. Two mutually-exclusive "should"s cannot be simultaneously true. Yes, in practice the maintainer's-discretion aspect of "should" would almost certainly govern (no matter which of the two is chosen), but IMO the existence of that escape hatch does not justify the existence of the two contradictory "should"s. I suppose, on consideration, that this boils down to me being a grumpy pedant about language - which isn't necessarily helpful in a discussion that's more related to technical merits... so on that basis, unless someone chimes in to agree with me that this is worth pursuing, I expect to drop the subject. (At least for purposes of this thread.) That's especially true since, now that I'm awake enough to think of it, the simplest (albeit not the most elegant) way to address the problem I see would be to revise the Recommends definition to something like "packages for which Depends does not apply, but which would be found together with this one in all but unusual installations" - and that's a moderately clunky construction, which smacks enough of pro-forma boilerplate to seem inappropriate for this sort of context. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: no{thing} build profiles
On 2018-10-25 at 20:00, Russ Allbery wrote: > Marvin Renich writes: > >> I certainly agree with you that 99.9% is clearly a wrong number for >> this. However I disagree that even 0.1% justifies using a different >> definition for Recommends than policy gives. > > libgpgme11 is not doing that. The library is literally unusable for its > actual technical purpose without gnupg installed, which clearly meets the > definition of Depends in Debian Policy: I'm not sure I remember seeing anyone say that it did not meet the definition of Depends - merely that it does meet the definition of Recommends. > The Depends field should be used if the depended-on package is > required for the depending package to provide a significant amount of > functionality. This does not actually seem to conflict with the "would be found together in all but unusual installations" definition for Recommends; in a case where the depending package can still provide meaningful functionality without the depended-on package, but will miss "a significant amount of functionality" if the latter package is not present, both definitions would seem equally applicable. If that's correct, then the definitions don't actually help indicate which relationship should be declared in such a case. That strikes me as a flaw in the definitions, quite possibly an unintended one, and (if so) potentially a bug worth fixing. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Debian Buster release to partially drop non-systemd support
On 2018-10-16 at 08:48, Philipp Kern wrote:
> On 2018-10-16 14:36, Ian Jackson wrote:
>
>> Philipp Kern writes ("Re: Debian Buster release to partially drop
>> non-systemd support"):
>>
>>> Could someone reiterate about what the current state of init
>>> diversity is supposed to be? Is it assumed to be best effort of
>>> every maintainer being required to ship an init script next to
>>> the systemd unit that is actually used by default[1]?
>>
>> I think describint that as `effort' is rather much.
>
> I don't understand. If I submit a merge request to the maintainer,
> it's on me to test what I submit actually works. So if I add stuff
> for a completely different init system I have to test it. The
> question is: Is the package buggy if it does not contain an init
> script but a systemd unit and it seems to be the case. Note that
> there are a *lot* of useful options in a systemd unit that would need
> emulation to make properly work with sysvinit.
To my eye, this resembles the situation I see with Websites and JavaScript.
My position is that any Webpage which does not inherently need to be
dynamic (as only a tiny fraction of them do) should have a fallback to
work "well enough" in an environment which lacks JavaScript.
Importantly, "well enough" does *not* mean "just as well".
One example I give of the difference is that once upon a time, when I
visited an article on the Website of the Washington Post in Firefox with
NoScript, the page would render with multiple screens' worth of blank
space (except possibly for a generic left-hand sidebar) at the top,
before the actual page content - the article itself - at the bottom.
That was in no way working "just as well" as the with-JavaScript case,
but it did let me read the article, so it did qualify as working "well
enough".
In the same way, I would opine that a package does not need to work
"just as well" via the init script as via the systemd unit in order to
qualify as having sufficient sysvinit support, but it does need to work
"well enough" that way. That is, not all the fancy bells and whistles
that could be make the package more useful or easier to work with or
suchlike necessarily need to be included, but the basic functionality
should be present.
(And I say that as a near-diehard sysvinit user, who finds the idea of
sysvinit being dropped from Debian a source of considerable stress.)
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
Re: Test message
On 2018-07-29 at 14:40, Jonathan Busby wrote: > I have been having problems posting to this mailing list so I'm using > pobox.com instead of my Gmail to see if that helps as per the > listmaster's suggestion. Gmail filters copies of your own messages, so that when the mailing list sends back to you a copy of what you sent out, you never see it. The idea is that since you already have a copy of the message (in your Sent folder or equivalent), and can find that copy easily via Gmail's search and smart-folders functionality, you don't need a second one, so there's no reason to waste space storing it. This ignores the reality that the "duplicate" message (determined by Message-ID) may have had modifications made to it after being sent out, as happens in the case of the mailing list. However, Gmail has been doing this for long enough that the odds of any change being made at this point are exceedingly slim. Basically, don't ever expect to receive via Gmail a copy of a message sent from that same Gmail account. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Firefox 60esr on Stretch ?
On 2018-05-04 at 12:22, Emilio Pozuelo Monfort wrote: > On 04/05/18 17:42, W. Martin Borgert wrote: >> How will we deal with breaking extensions? >> >> E.g. I'm using xul-ext-scrapbook a lot. AFAIK, upstream does not >> provide a post-XUL version. Probably other extensions will face the >> same compatibility issue. >> >> Should we just remove them from stable? > > I guess so, yes. There's not much we can do if there is no support > for newer versions. Though please do take note of other applications which may still work with them. Even leaving other Mozilla-based browsers aside, ISTR there being (or having been?) some extensions which would work just fine in both Firefox and Thunderbird, and since Thunderbird is retaining XUL support - at least for now - there may be some value in retaining such "overlap" extensions for people who use them there. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Please do not drop Python 2 modules
On 2018-04-25 at 06:46, Scott Kitterman wrote: > On April 25, 2018 5:51:54 AM UTC, Andrea Bolognani > wrote: > >> On Tue, Apr 24, 2018 at 11:17:08PM +, Jeremy Stanley wrote: >>> Given that "software collections" provides a containerized Python >>> 3 build and basically none of the rest of the Python ecosystem >>> modules outside the stdlib (which would all require manual >>> rebuilding against it), this is nowhere close to the same as >>> providing an optional Python interpreter within the global >>> system context as Debian has done. At least the projects I work >>> on don't see RHEL software collections Python 3 as remotely >>> supportable. >> >> Fair enough; the point about distribution with lifecycles closer >> to Debian's keeping Python 2 around for a while after switching >> their default to Python 3 still stands. > > In Debian there's no such thing as a 'default' python. There's none > in a minimal install. All that ends up on a system is what is pulled > in by dependency. The word "default" means different things in different contexts and to different people, and the one you cite (which I parse as being roughly "installed automatically as part of the distribution") is only one of them. It is true that there is no such thing as "the version of Python which will be present in a (default / minimal) install of Debian". However, there is such a thing as "the version of Python which will be present in a default install of Python on Debian" - meaning, an install of Python on Debian with no version explicitly specified - and it is reasonable to refer to that latter as "Debian's default version of Python". The simple, obvious means of installing Python in Debian - either manually, or as a dependency of another package - is via the package named 'python'. At present, in current testing, doing this will pull in python2.7 and will not (as far as I can see) pull in anything named python3*. That is enough to qualify Python 2 as "the Python which will be present in a default install of Python on Debian", and therefore as "Debian's default version of Python". -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: problems in gjots2 and Debian
On 2018-04-18 at 10:53, Ansgar Burchardt wrote: > On Wed, 2018-04-18 at 10:45 -0400, The Wanderer wrote: > >> On 2018-04-18 at 05:55, Andrey Rahmatullin wrote: >>> But that didn't happen, unless you put different meaning into >>> Maintainer and Uploaders. >> >> If you don't assign different meanings to "Maintainer:" and >> "Uploaders:", what's the point in both fields existing? > > The Maintainer field is only allowed to list one person for historic > reasons. So a new field was added to list additional maintainers. If it really is intended that the listed Maintainer be on an equal footing with any and all listed Uploaders, and there's no semantic difference between these fields - just the arbitrary limitation that one of them can't have more than one entry - wouldn't it make sense to deprecate the Maintainer: field, and move towards using Uploaders: only? I'm not sure that would be a good idea, but it would at least avoid the apparent misunderstanding of the meaning of the roles which seems to have underlain some of the dispute in this case, and eliminating meaningless redundancy in a spec is generally a good thing. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: problems in gjots2 and Debian
On 2018-04-18 at 05:55, Andrey Rahmatullin wrote: > On Wed, Apr 18, 2018 at 11:23:23AM +0200, Martin Steigerwald wrote: > >> As just someone who mostly maintains one package (fio - flexible >> I/O tester) I can certainly understand how you feel about that >> Lucas removed you as a maintainer. > > But that didn't happen, unless you put different meaning into > Maintainer and Uploaders. If you don't assign different meanings to "Maintainer:" and "Uploaders:", what's the point in both fields existing? -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Debian part of a version number when epoch is bumped
On 2018-04-02 at 15:41, Simon McVittie wrote: > On Mon, 02 Apr 2018 at 20:30:54 +0200, Christian T. Steigies wrote: > >> I don't understand why everybody is so afraid of an epoch, but ok. > > It's a source of confusion (and confusing side-effects) that, once > added, can never be removed, however many upstream releases might > happen. I thought that in theory, if the upstream version later increases to the point where it would sort above the with-an-epoch version (whether because it's a date-based version and new versions keep coming out all the way into the next millennium, or because the upstream version scheme changes again, or whatever else), the epoch could potentially be dropped without introducing issues. Is that wrong? If so, I'd be interested to see an example of a case where problems would result, because while I can intellectually conceive of there being such I so far haven't been able to think of any. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Extended Long Term Support for Wheezy, CIP
On 2018-02-22 at 09:45, Geert Stappers wrote: > On Thu, Feb 22, 2018 at 02:57:07PM +0100, Raphael Hertzog wrote: >> On Thu, 22 Feb 2018, Philip Hands wrote: >> >>> I'm in favour of making it possible for our users to build >>> structures that enable longer support periods if that's what they >>> require. There would seem to be a need for an OS that would have >>> support measured in decades rather than years, and we should not >>> get in the way of Debian being that OS. >> >> Indeed. And it's the reason why I mentionned CIP in my initial >> mail. They are not interested in longer support for wheezy (too >> early for them) but they are interested in working with us and >> helping us to make this possible as part of Debian. One of the >> persons I am in contact with mentioned that CIP members could (at >> some point) contribute security updates within Debian. >> >> Looking a bit further, I see a way forward where we have the >> security team (first 3 years), the LTS team (next 2 years), CIP >> members (next 10 years) taking over the charge of security updates >> for a given release. >> >> And indeed if we prepare the infrastructure for this by finding a >> way to host the updates for wheezy for longer than expected, we >> pave the way for CIP to take over security maintenance of our old >> releases. > But what is "CIP"? > > > My websearch did bring up "Clean In Place" and "Christelijk > Intromatie Platform" ... Referring back to Raphael's original mail, it would appear to stand for "Civil Infrastructure Project". -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: What can Debian do to provide complex applications to its users?
On 2018-02-19 at 16:03, Adrian Bunk wrote: > On Mon, Feb 19, 2018 at 03:52:30PM -0500, Roberto C. Sánchez wrote: > >> On Mon, Feb 19, 2018 at 10:16:56PM +0200, Adrian Bunk wrote: >>> Debian already does "security by upstream releases" for Firefox, >>> and this clearly shows why this is problematic: >> >> Also PostgreSQL, formerly MySQL, OpenJDK, etc. Some go smoothly (I >> think PostgreSQL upstream is very good here), and some do not. > > These (and also the kernel) are "following an upstream LTS branch", > not "security by upstream releases". > > Also for Firefox the new releases on an upstrem LTS branch (currently > 52) are usually not a problem. > > The problem with Firefox is the once per year switch to a new LTS > branch, like this year Firefox 52 -> 59. We aren't doing that for > PostgreSQL. Nit: the new Firefox ESR this year will apparently be version 60, not 59. They've postponed it by one release this time around, for reasons I haven't bothered to retain. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Debian Stretch new user report (vs Linux Mint)
On 2017-12-01 at 16:44, Sven Hartge wrote: > Luca Capello wrote: > >> On Fri, 01 Dec 2017 14:59:53 -0500, James McCoy wrote: > >>> People seem to be skipping over the fact that even after ntfs-3g >>> was installed, the user only had RO access. That's the bigger >>> issue. > >> Exactly, which IIRC is the normal behavior if the NTFS filesystem >> was not properly "closed", e.g. if Windows was hibernated (or it >> uses the Fast Boot/Startup feature, thus suspend2both). > > Which is normal since at least Windows 7, maybe even Vista, to not > shutdown completely, but only shutdown the applications and then > hibernate the remaining Windows Kernel and memory to disk, leaving > the filesystem unclean. Are you sure? I've been managing Windows 7 at my workplace for years now, and I've never seen this "suspend in response to Shut Down" behavior there; the first place I ever saw it was on a Windows 8 machine. I'm not sure I've yet seen it in our current Windows 10 pilot, either, but I also haven't looked especially closely there. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: virtualbox-guest-utils as time server.
On 2017-10-09 at 15:28, Andrey Rahmatullin wrote: > On Mon, Oct 09, 2017 at 08:56:25PM +0200, Jörg Frings-Fürst wrote: >> The main problem is that the ntp server was not designed to run >> inside of a virtual machine. But is here is a server. > > Sorry, I don't understand this. I think I parse this as saying that the VM in question *is* a (virtual) server, and as such needs to run server software (including time-server software) for the benefit of other systems. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Whether remotely running software is considered "software" for Debian.
On 2017-08-28 at 07:59, Dr. Bas Wijnen wrote: > On Mon, Aug 28, 2017 at 12:31:15PM +0200, Philipp Kern wrote: >> The existence of that API in the form of the client is a >> documentation that should be sufficient to reproduce a server that >> can communicate with the client. Do we expect that someone does >> that work before a client implementation for a protocol can land? > > I think if someone wants to write a client with the purpose of > interacting with a non-free service, that client should go in contrib > and there is nothing wrong with that. I find the obsession that some > people seem to have with getting their software in main startling. > Why should software be in main if its purpose is to work with > non-free software? That's exactly what we have contrib for. One plausible rationale for this is accessibility to end users, and that goes back exactly to your other point about what repository configuration should be the default. As things currently stand, with main enabled by default but contrib and non-free not, the directions for a user to get a package from main installed consist of one trivial step: apt-get install [packagename] However, for the same user to get a package from contrib installed, the directions consist of three steps, of which one is - while still easy and straightforward - less trivial, in that it does not consist of a single easily-memorable command: [add contrib to sources.list] apt-get update apt-get install [packagename] Minor though it may be in the grand scheme of things, this added barrier - which is in place intentionally, if I'm not mistaken, as part of enabling that same free-software bubble you cited in an earlier mail - is enough to provide an incentive for preferring a package to be in main. There's also the fact that it's repeatedly stated that anything not in main is not part of Debian; it's easy to see why a maintainer would want to have a package in Debian, rather than having it be a second-class citizen. Switching the default repository configuration so that contrib and non-free are enabled, while also becoming more rigid and rigorous about the requirements for what can be in main, would simultaneously improve the out-of-the-box experience for many users and make it more practical for those (such as yourself, and in some circumstances myself) who want that free-software bubble to get it. Adding a 'firmware' repository (and even enabling it by default), while it would similarly both improve that out-of-the-box experience and make the free-software bubble easier to achieve for those who want it, would not remove the "accessibility to end users" barrier which provides incentive for maintainers to want their packages to be in main. Perhaps adding that 'firmware' repository and enabling both it and contrib by default, while keeping non-free disabled by default, would be the most optimal solution? Although that would seem to imply a change in what is considered "part of Debian", which might be controversial. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Bug#860170: node-brfs -- browserify fs.readFileSync() static asset inliner
On 2017-04-14 at 09:34, Wouter Verhelst wrote:
> On Thu, Apr 13, 2017 at 10:13:40AM +0300, Lars Wirzenius wrote:
>
>> On Thu, Apr 13, 2017 at 08:59:30AM +0200, Wouter Verhelst wrote:
>>> (or the letter h followed by a vowel)
>>
>> A hat, a hotel. a helmet. Unless the speaker has a dialect where
>> they're an hat ("an 'at"), etc. It seems Cockney is one such
>> dialect.
>
> Yes, you're right of course. I was thinking of a specific example
> (don't remember which one anymore) where the word was *written* with
> an H at the start, but the H was not pronounced; I just wrote it
> down incorrectly.
At a guess, probably "herb", which is commonly pronounced without the
initial aspirant even in dialects (etc.) which ordinarily don't elide
such.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
Re: Non-free RFCs in stretch
On 2017-03-07 at 11:40, Ian Jackson wrote:
> Adam Borowski writes ("Re: Non-free RFCs in stretch"):
>
>> On Tue, Mar 07, 2017 at 02:48:59PM +, Ian Jackson wrote:
>>
>>> I have a suggestion for how this could be done.
>>>
>>> We give each reason-why-a-package-might-be-nonfree-or-contrib a
>>> name in the package namespace. I'm going to call these packages
>>> antimetapackages.
>>>
>>> Each package in non-free or contrib must Recommend all the
>>> antimetapackages which apply.
>>
>> Why Recommend rather than Depend? The latter would allow a hard
>> conflict with everything with a specific kind of badness, which
>> seems exactly like the thing people here are looking for.
>
> Did you see where I wrote:
>
> We use Recommends because these are all policy decisions which the
> user may wish to override on an individual basis.
>
> The point being that it is for Debian to advise and inform users,
> but ultimately the user should have the freedom to make their own
> compromises. So we should assist the user to implement their
> personal policy. But we mustn't _insist_ on the user following their
> own policy as expressed, probably inaccurately, in our dependency
> system.
>
> In practical terms, apt makes it very hard to maintain a system
> where a Depends is violated. Conversely it provides a good sticky
> door (in the default configuration, at least) to avoid unintentional
> violation of Recommends, but once a Recommends is violated it doesn't
> cause further problems.
Can you provide an example of how, under your proposal, someone who
wants to - e.g. - forbid the installation of any nonfree-gfdl-invariant
packages would do so? I don't see any way to accomplish that based on
Recommends:, precisely because Recommends: can be overridden.
For "Depends: foo", I'd probably try to do it by pinning foo to priority
-1, or something along those lines - but such a pin would do nothing to
prevent packages which only Recommend foo.
I could see a possible way of doing this with Conflicts: or similar,
such that you just install the packages which the ones you want to
prohibit will conflict with - but trying to set up a suitable collection
of antimetapackages to be conflicted against seems like a recipe for
madness.
I hope I'm just missing something, because this looks like a very
interesting idea. With Recommends:, however, it looks like it would do
nothing more than potentially warn the user at install time that a
package which is about to be installed violates this particular freedom
condition - and that doesn't seem like enough of a benefit to be worth
the investment.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
Re: SPAM
On 2017-03-03 at 23:36, Ben Finney wrote: > The Wanderer writes: > >> In this case, either it's faked up to look as if it's coming from >> the person listed in the From: address but that person has actually >> never seen the message before it reaches us, or it was faked up >> when being sent _to_ that person (to appear as if it had come from >> the mailing list) and we don't even have the headers of the actual >> original spam. > > That's my tentative conclusion also. There is a commonality to all > these “don't send me this spam” messages, that essentially combine a > plausible complaint top-posted on a quoted spam message. > > I think the best explanation is that the entire message – complaint > and quoted part – were composed and sent by the spammer themselves. That was my original conclusion, but Philip Hands presented a persuasive argument otherwise on this same mailing list just this past week, so I now allow for both possibilities. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: SPAM
On 2017-03-03 at 20:54, Christopher Clements wrote: > On Fri, Mar 03, 2017 at 12:40:52PM +0300, The Illuminati wrote: > >> Listen up shitty ass spam bot. I'm really Gabe Newell and I can track your >> fucking IP >> On Tue, Jan 10, 2017 at 1:04 PM, CHOICEHOMEWARRANTY <[1]a...@sigxcpu.org> >> wrote: >> [SPAM] > > Does anyone on this list file "abuse@" reports, or does everyone > assume that someone else does? I assume that most spam nowadays, especially spam such as the message which you quote, is faked up sufficiently that there is no practical way to identify which domain to report the abuse to. In this case, either it's faked up to look as if it's coming from the person listed in the From: address but that person has actually never seen the message before it reaches us, or it was faked up when being sent _to_ that person (to appear as if it had come from the mailing list) and we don't even have the headers of the actual original spam. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Bug#829076: general: Random freezes but the mouse can still move
On 2017-02-26 at 09:01, Lars Wirzenius wrote: > * John Cuffs tells Lee to "shut the fuck up", and quotes a spam that > isn't visible (anymore?) in the bug log. Just to note: this almost certainly wasn't actually addressing any of the thread participants, and also probably wasn't posted by John Cuffs. This is a standard form of spam that I've been seeing on mailing lists; my assessment of the form indicates that the "original" spam message was never actually sent, the spammer is instead sending a fake "reply" which quotes the spam message and has headers (etc.) as if it were a response by J. Random Netizen to a message already posted in some random thread. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
github and its workflows (was Re: manpages.debian.org has been modernized!)
On 2017-01-30 at 07:38, Bernd Zeimetz wrote: > On 01/30/2017 01:32 PM, The Wanderer wrote: > >> If someone isn't cloning the repository locally, how is that >> someone creating the patch which is in the git repo which is >> requested to be pulled? > > Choose a random file in a random repository you are not allowed to > commit to. Click on the edit button. Ack that github will create a > fork to edit the file. Make your changes. Click on save and on create > a pull request... just a few clicks... ...bwah? I deleted my "unless github has incorporated an _editor interface_ now" comment, because I thought that was too tangential and off-the-wall to bring up even as a hypothetical. Are you saying that people are writing and submitting patches via a Web-based editor interface, and that you're recommending that people consider _accepting_ those patches, when they haven't even been _build-tested_ before submission (because you can't build-test - much less actually _test_ - without the full source tree, which you'd obtain by pulling the repo)? Maybe I'm missing something, or maybe I'm just backwards, but that sounds _insane_ to me. (I imagine it would be _possible_ to have a workflow of something like "clone the repo, edit and test locally, copy-and-paste the full contents of the edited source files one-by-one into the editor interface", just to avoid 'git push' - but that seems like overkill, and would still involve cloning the repo.) If github really is encouraging that sort of thing (by including such an editor interface) - as well as the "keep the only copy of your fork in the same centralized location as the original code" mindset implied by a don't-bother-to-clone-a-local-copy workflow - that leaves me considerably less comfortable with the idea of people using github than I used to be. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: manpages.debian.org has been modernized!
On 2017-01-30 at 03:54, Bernd Zeimetz wrote: > On 01/30/2017 12:44 AM, Sean Whitton wrote: >>> Same here. Also since I've moved my major packages to github, a >>> constant stream of pull requests for even simple bugs like typos >>> is coming in. People are used to github and how to create a pull >>> request on the web interface, and I can just merge these changes >>> with a few clicks. >> >> Please don't forget about git-request-pull(1), or it's simpler >> cousin, "to fix this bug please merge branch foo from repo bar". > > That still involves cloning re pository, pushing stuff... Using a web > interface is much more easy - and works well even on a tablet. And > even people who don't know how to use the cosole are able to handle > it. If someone isn't cloning the repository locally, how is that someone creating the patch which is in the git repo which is requested to be pulled? And if someone isn't pushing that locally-cloned repo back to github, how is that someone getting the local changes into github to be pulled? (AFAIK, the official way of getting your local changes into github is with 'git push'; at least that's what I had to use the one time I tried to work with github other than to clone a repo hosted there, although admittedly my network situation is a bit unusual.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Is missing SysV-init support a bug?
On 2016-10-17 at 17:53, Bart Schouten wrote: > Nikolaus Rath schreef op 17-10-2016 18:26: > >> On Oct 17 2016, Bart Schouten wrote: >> >>> (And I write SystemD with caps because that makes it easier to >>> read, people invented capitals for a reason). >> >> What would you think some people consistently spelled your name as >> Bart SchouteN with the same justification? > > I would consider that bigotry as SystemD is short pretty much for > System Daemon. While this is a reasonable point, it doesn't invalidate Nikolas' point: that the people behind the systemd project A: do not consider it to be spelled that way (and, yes, capitalization is part of correct spelling, at least when it comes to names), B: are likely to perceive the refusal to spell it in the way which they see as correct to be a sign of hostility, and C: are likely to react accordingly to that perceived hostility. >> And if that set of people also happened to coincide exactly with >> your most vocal critics? >> >> How you write your emails is up to you, but you're not making it >> likely for them to be well received. > > Because I write the name of a project in the most reasonable > capitalized form. Without taking sides on the question at hand: do you, then, spell the name of the distribution as DebIan? -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Debian does not have customers
On 2016-09-23 at 19:12, Russ Allbery wrote: > Bart Schouten writes: > >> I think the point that people are trying to get across is that a >> lot of what you say Russ feels like excuses. > > An excuse is when you know you should do something but aren't going > to do so, and are trying to justify that decision to oneself. While I see the perspective which leads you to that statement, I don't think that's strictly correct. The way I usually put it is that "if you expect to be excused because of it, it's an excuse". Some excuses are valid, mind. That doesn't mean they aren't excuses. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Debian does not have customers
On 2016-09-20 at 19:00, Santiago Vila wrote: > [ Please don't Cc:me ] > > On Tue, Sep 20, 2016 at 11:29:14PM +0200, Abou Al Montacir wrote: > >> Can you please explain to me how do you understand the following >> statements in the DSC? > > Of course I can. > >> 3. We will not hide problems [...] > > This means the BTS is visible to everybody, even anonymously. In > other words, the BTS is not facebook, it's the old good open web. > > It does not mean anybody has the right to decide on what bug I will > be working tomorrow, because we are an organization made by > volunteers. I think the logic here is something like: A closed bug is presumptively a fixed bug (because bugs which have been fixed get closed). An open bug is presumptively a non-fixed bug. Therefore, to close a bug which has not been fixed is to pretend that the problem reported in that bug has been fixed, i.e., does not currently exist. Therefore, to close a bug which has not been fixed is to attempt to hide the problem reported in that bug, by making it appear as though that bug has been fixed. Russ has provided a rationale for why leaving insufficient-data bugs open is not a good idea for many kinds of projects, and I believe for why Debian would be one of them; I'm not sure I necessarily accept that rationale, but it is a solid one. That doesn't invalidate the above logic, however, only explain why it may not be able to prevail in the circumstances which we have to live under. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Debian does not have customers, but users
On 2016-09-18 at 08:40, Santiago Vila wrote: > On Sun, Sep 18, 2016 at 02:00:26PM +0200, Abou Al Montacir wrote: > >> you will end being a community of geeks developing SW for >> themselves only. > > Debian is a volunteer project made by its users. > > So we are already a community developing SW for ourselves, the > users, and there is nothing wrong with that. > > Once you realize that "people making Debian" and "its users" are > really the same thing, you will see why this discussion does not make > much sense. One nitpick: There are many, many people who are users of Debian who do not contribute to the development of Debian, except possibly by way of filing bug reports. As such, "people making Debian" is at most a subset of "users of Debian", not another term for the same set. Yes, the developers of Debian are developing software for themselves - but I'm pretty sure the point of what you quoted is in the word "only", which you omitted from your rephrasing, and I'm not at all sure even all Debian contributors would agree that they are contributing to Debian _only_ for themselves and other Debian contributors. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Debian does not have customers
On 2016-09-15 at 22:03, Ben Finney wrote: > The Wanderer writes: > >> On 2016-09-15 at 21:26, Wookey wrote: >> >>> I reckon a lot of us would be happier if you [Russ] (and Abou) >>> used the term 'users', rather than 'customers'. I know I think >>> that being a customer involves payment. >> >> That was exactly my point: that although many people (including >> me!) think that [the term “customer” entails payment from the >> customer], other people do not - and, IMO, refusing or otherwise >> failing to understand what they mean when they use the term that >> way is not helpful. > > That's a point of disagreement, then. I think Russ's drawing > attention to the fact Debian does not have customers is helpful: it > clarifies the discussion and explicitly acknowledges a fact that may > have been ignored by the person using that term ambiguously. > > As Russ describes so eloquently, that ambiguity glosses an essential > distinction the Debian Project has from other superficially similar > entities people may be more familiar with. > > Ignoring that distinction is harmful to effective communication, > because it fosters an unachievable expectation. Effort to expose and > avoid that particular ambiguity is helpful because it dispels a false > expectation. I would agree with all of that. I simply maintain that to say that "we don't sell anything, therefore we don't have customers" (as is the original statement to which I responded) is to fail to effectively communicate, by failing to respond to the meaning of the term which the person who used it intended. That's not to say that we have to accept and adopt that intended meaning of that term; providing an explanation of why it is not suitable for Debian (perhaps by linking to an existing explanation, for which purpose Russ's own might be a candidate) could well be a more suitable option. To see people talking past each other because they're using different definitions of their words and aren't acknowledging that fact, however, is actively unpleasant for me. Russ _is_ acknowledging that fact, and may well be helping bring the difference into light for others; however, the original comment to which I responded did not seem to be doing so. (At this point, I don't think continuing this subthread any further is likely to be particularly helpful...) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Bug#837606: general: system freeze
On 2016-09-15 at 21:26, Wookey wrote: > On 2016-09-15 18:04 -0700, Russ Allbery wrote: > >> Debian is delightfully different. We care about market share of >> *volunteers*, but we don't have to care (and indeed, I personally >> don't care at all) about market share of *customers*. > > Well put, but I reckon a lot of us would be happier if you (and > Abou) used the term 'users', rather than 'customers'. I know I think > that being a customer involves payment. That was exactly my point: that although many people (including me!) think that it does, other people do not - and, IMO, refusing or otherwise failing to understand what they mean when they use the term that way is not helpful. There's a seed of a colorable argument otherwise in Russ's mail, however, so I don't intend to push that terribly hard - especially not given that the entire discussion would be at best arguably on-topic. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Bug#837606: general: system freeze
On 2016-09-15 at 16:17, gregor herrmann wrote: > On Thu, 15 Sep 2016 16:58:03 +0200, Abou Al Montacir wrote: >> We don't care to loose customers because of an issue faced by >> someone, > > Debian can't lose customers because we have no customers because > we're not selling anything. This is a terminology difference. Some people think of "customers" only in context of buying and selling, including the selling of services. Others think of it in terms of the provision of any service, regardless of whether for compensation or not. For example, in my department at my workplace, the people in other parts of the organization to whom we provide computer support are called our (and our department's) "customers" - even though we don't charge them for the service. I think the key elements might be something like "we are offering something which we want them to accept, and they are relying on that offer". That doesn't quite sum it up perfectly (it doesn't account or the fact that, as I understand this broader sense of the word, one could argue that e.g. a DD who uploads a package that needs validation through the NEW queue is a customer of the ftpmasters), but it's as close as I've managed to come thus far. > As a consequence I still think that unspecific "bug reports" to > 'general' don't achieve more than frustrating both the reporter and > the subscribers of debian-devel, and that we should try to find > alternative ways for channeling such support requests. Albeit (for reasons I can't seem to pin down into verbal form) somewhat reluctantly, I have to agree with this. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Bug#837606: general: system freeze
On 2016-09-15 at 13:24, Russ Allbery wrote: > Abou Al Montacir writes: > >> Does improve distribution means hiding issues? I don't think it >> is. > > You keep using this term, but I have no idea what you mean by it. > What information do you feel like we're hiding? I suspect that he feels that closing a bug report without having first tried to address it equals pretending that the problem reported in the bug report does not exist, and thus, represents an attempt to hide the fact that the problem does exist. Given all the surrounding facts (some of which you've cited, quite validly, in this thread), I'm not sure he's right, but - at least from the outside, and as a general matter - the perception does seem to be a reasonable one. Which only means that this represents a potential PR problem, albeit perhaps a minor one. > Not listing that line item in a bug page basically no one looks at > isn't "hiding information" in any meaningful sense that I can see. In the perspective involved, it would be an attempt to hide the fact that the problem was reported, and therefore that the problem apparently existed. > Basically, you're attributing to the Debian project considerably > more resources, expertise, data management, bug classification, and > analysis capabilities than we actually have, and then (apparently) > getting angry and frustrated that we we're (from your perspective) > somehow withholding those capabilities from this bug specifically. > But that's not what's happening at all! We have only a tiny fraction > of the resources that you seem to think we have, and we're just > trying to be explicit about what we can and can't do rather than > having people's bug reports quietly disappear with no response. 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. "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. (Also, the former can more easily lead to "existing bug report discovered, attempt is now made to fix it" or to "existing bug report discovered, further information added which may be useful for a fix" than can the latter.) Which is probably to say that eliminating, or at the least reworking, the 'general' package as a target for bug reports would probably be an improvement if done properly. I'm not terribly fond of it as an idea at first glance, but the logic behind it does seem fairly strong. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Use and abuse of the unreproducible tag
On 2016-09-13 at 12:25, Adam D. Barratt wrote: > On 2016-09-13 12:55, Sebastiaan Couwenberg wrote: > >> On 09/13/2016 01:49 PM, Santiago Vila wrote: >> >>> You can't reproduce it, or you don't want to reproduce it? >> >> I added the tag because I couldn't reproduce the issue in unstable >> where we build our packages. It's great that it's reproducible in >> testing, but we don't upload to testing. > > Sometimes we do... > > In any case, that's not the point. Testing is what will become > stable. Packages in stable need to be buildable on stable (for > security updates and point releases) and "does the package currently > build in testing?" is the best approximation we can have to "will the > package build when it's in stable?". Not to mention, building for upload isn't the only valid - or, AFAIK, the only supported - reason to want to build in a given release. Users of Debian - including both testing and stable - may want to rebuild a given package themselves, perhaps with local modifications, for use in the release which they are running; my understanding is that this is considered something that's desirable to support, at least as a matter of philosophy. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Subjects and threads
On 2016-09-04 at 07:59, Jonathan de Boyne Pollard wrote: > Adam D. Barratt: > >> I'm sure I'm not the only one irritated by this, > > Then you should be looking at the Debian software that drives > https://lists.debian.org/ , which seriously mucks up subject > processing, and not at us poor users who are long-suffering under it. > Debian software gets References: wrong, too; which is in fact the way > that one recognizes replies. Counterpoint: I see messages threaded hierarchically under one another, as is correct, with no issues, on all Debian mailing lists to which I subscribe. Checking a few messages randomly (from this thread, including at least two of your own) shows that the References: header is populated, and that the Message-ID(s) with which it is populated refer to the parent message in the thread and/or to the grandparent, exactly as would seem to be appropriate. IOW, the evidence immediately available to me seems to indicate that your claim is not correct. Moreover, even if the mailing list software did/does get this wrong, that would not be an excuse for dropping the Re: from the Subject line. That flag is not only (and, indeed, properly not at all) for use by the mail client; it is also to provide information to the person who reads the mail, as it provides a better indication that "this mail is a reply" than is otherwise available at a glance. (Certainly the mail-reader cannot be expected to check References: headers manually every time they look at the list of available messages.) To arbitrarily drop that additional flag would require more reason than "just because". -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: libsystemd
On 2016-08-28 at 09:11, Jonathan de Boyne Pollard wrote: > The Wanderer: > >> IMO this level of integration between things which are not mutually >> interdependent is a minor bug in itself, but none of the >> maintainers are going to agree with me on that. > > Actually, they might. But this is a facet of the Debian build system > in general, and not specific to systemd. It's more egregious in the case of libsystemd than in many other cases, because of the purpose of the package and the rarity with which changes related to that package will appear in the changelog - but yes, this isn't the _fault_ of systemd as such. > You'll find a lot of packages in Debian where many binary packages > are built from a single source package, and you'll see this same > effect for many if not most of them. It's possible to have separate > binary package changelogs within a single source tree. But it's > quite hard, and like other "unusual" things (such as building > packages into the current directory) the Debian build system rather > fights against it. This is true, and even I am not entirely convinced that the benefit of more readable / understandable (and less cluttered) changelogs would be worth the effort which would have to be invested to achieve that result. Having thought it through in a bit more detail, I wouldn't be surprised if the nature of libsystemd would mean simply that there will _never_ be a systemd changelog entry relevant to someone who uses only libsystemd and not the rest of the suite - in which case the systemd sections of the apt-listchanges report can simply be skipped over when only libsystemd0 is being upgraded. For the udev side of things the question is more difficult. I do think that udev should not be built from the systemd source package, but should be/have a separate source package of its own; however, my understanding is that that's essentially a "this is how it's hosted / maintained upstream" matter, and that upstream considers changing this to be a nonstarter. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: libsystemd [was: Re: Is missing SysV-init support a bug?]
On 2016-08-27 at 06:26, Andrew Shadura wrote: > On 27 August 2016 at 10:33, Dmitry Bogatov wrote: > >> Like compat package, which provides libsystemd.a static library >> and headers, that mirrors interface of libsystemd. This library >> would forward call to actual libsystemd, if it exists and return >> error, if it does not. >> >> Probably, this method can be used with other libraries, like >> libaudit or libdbus. > > You're going to be surprised to learn such library exists. > > It is called libsystemd. There is one minor/cosmetic downside of libsystemd as currently provided, however: the apt-listchanges changelog. The only '*systemd*' package which I have installed is libsystemd0. However, whenever I dist-upgrade (which is at least weekly if not daily, against testing) and a new version of libsystemd0 gets installed, apt-listchanges shows me what appears to be the changelog for the systemd source package - which rarely (if ever) includes anything about changes which seem to relate to libsystemd0 itself, only to the larger suite of programs for which it serves as a stub layer. Having to wade through that frequently fairly large list, just on the off-chance there's anything which will affect code that's actually being changed on my system, is a pain. (It's actually worse than that, because this would happen even if I also removed libsystemd0; this same systemd-source-package(?) changelog appears to be displayed on upgrades of _udev_, for no apparent reason beyond udev now apparently(?) being maintained as part of that same umbrella suite of software - and indeed, changes to udev _are_ sometimes mentioned in the 'systemd' changelog and apparently are not mentioned elsewhere, which means I do need to wade through that changelog in case anything relevant is mentioned. IMO this level of integration between things which are not mutually interdependent is a minor bug in itself, but none of the maintainers are going to agree with me on that.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: mk-build-deps cannot install particular version of Build-Depends packages
On 2016-08-25 at 23:06, Paul Wise wrote: > On Thu, Aug 25, 2016 at 9:29 PM, The Wanderer wrote: >> If there exists a dependency solution which will achieve the >> result requested on the command line (here, installing the lower >> version of the depended-on package), that solution should be chosen >> over any which do not achieve that result; if that solution >> involves removing or downgrading packages, it should be presented >> for confirmation before proceeding. > > I don't think that apt should step outside the configured priorities > without instruction from the user. Since apt doesn't currently > interact with the user (but aptitude does), it can only print an > error. That error could be improved with info about alternative > solutions to try that are outside the configured priorities, using > the -t suite and somepkg/suite syntax. To clarify or expand on my previous request somewhat: What I read you as saying is essentially that in the case of multiple repositories with differing configured priorities, you think that a dependency solution which does not adhere to those priorities should not be considered to exist, for purposes of my statement above. I might be persuaded to agree with that, but at least at a first impression, I don't think I do. I think that what the user has requested on the command line should be considered the top priority, so that it is always possible (with sufficiently clear and explicit syntax) to temporarily override the "global" priority settings - rather than having to manually edit those settings, do this install run, then revert the edit. The fact that such a departure from the configured "global" priorities is being made should indeed be made very clear in an install-time prompt, but I am not immediately convinced that it would be better to fail with an informative error rather than to present such a prompt. At the very least, any such error should include a statement of the fact that a solution which would violate the configured priorities does exist, and explain which priorities need to be adjusted (and/or at least which package versions, from which repositories having which current priorities, would satisfy it) in order for that solution to not be ruled out in this way. > That said, in this case the solution is within the configured > priorities so apt could do better. Agreed. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: mk-build-deps cannot install particular version of Build-Depends packages
On 2016-08-25 at 23:06, Paul Wise wrote: > On Thu, Aug 25, 2016 at 9:29 PM, The Wanderer wrote: > >> In other words: the problem here is the fact that apt's priorities >> in this regard are messed up. > > The same will happen with custom priorities set. I am referring not to repository priorities, or similar, but to the priority which it places on achieving the requested result vs. doing something else. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: mk-build-deps cannot install particular version of Build-Depends packages
On 2016-08-25 at 09:04, Adam D. Barratt wrote: > On 2016-08-25 10:44, Исаев Виталий wrote: > >> Build-Depends: debhelper (>= 9), cmake, >> flatbuffers (= 1.2.0-1), > > This has nothing to do with mk-build-deps. Given this: > >> ➜ apt-cache policy flatbuffers >> flatbuffers: >> Installed: (none) >> Candidate: 1.4.0-17 >> Version table: >> 1.4.0-17 500 >> 500 http://repo12.mailbuild-2.embarce.ro xenial/local amd64 Packages >> 1.2.0-1 500 >> 500 http://repo12.mailbuild-2.embarce.ro xenial/local amd64 Packages > > apt will prefer to install the latest available version, as listed in > the candidate field, as demonstrated in: > >> Starting 2 pkgProblemResolver with broken count: 1 >> Investigating (0) libhole-cpp-build-deps [ amd64 ] < 1.0.1ubuntu1 > ( >> devel ) >> Broken libhole-cpp-build-deps:amd64 Depends on flatbuffers [ amd64 ] < >> none -> 1.4.0-17 > ( devel ) (= 1.2.0-1) >> Considering flatbuffers:amd64 0 as a solution to >> libhole-cpp-build-deps:amd64 -2 >> Removing libhole-cpp-build-deps:amd64 rather than change >> flatbuffers:amd64 In other words: the problem here is the fact that apt's priorities in this regard are messed up. If there exists a dependency solution which will achieve the result requested on the command line (here, installing the lower version of the depended-on package), that solution should be chosen over any which do not achieve that result; if that solution involves removing or downgrading packages, it should be presented for confirmation before proceeding. If - as is apparently the case - apt does not presently do that, that should IMO be considered a bug. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Reply headers vs. in-mail requests (was Re: Bad news to CUDA applications (was: Re: GCC 6 & binutils for the Debian stretch release))
On 2016-07-01 at 08:43, Jonathan Dowland wrote: > On Fri, Jul 01, 2016 at 06:07:27AM +, lumin wrote: > >> (please keep me in CC list) > > I suggest setting the headers to make this automatic rather than > asking people to remember to do it :) I'm pretty sure there is no header setting which will make this fully automatic. For one thing, he can only control header settings on mails which he sends, not on mails which other people send in reply to those mails. If he wants to be CCed on replies to those replies, as far as I know there is no header which he can set which will make that happen. For another thing, some replying practices will ignore such headers. I normally reply to list mail using Thunderbird/Icedove's "Reply to List" button, which addresses the reply only to the mailing list itself, ignoring any headers which may be set to direct replies elsewhere. I do this because otherwise the reply tends to be directed either to the original sender rather than to the list (with "Reply", in the absence of Reply-To set to the list address), or to all recipients (with "Reply All"), depending on what headers are present - and IMO neither of those is the correct default. The presence of a comment such as this one informs me that I may want to vary that practice in a given case. (I haven't done so in this case since this mail is no longer on the topic which he raised, so I don't have good reason to expect him to be interested in it.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Bug#823465: dpkg: Won't run at all on i586 Pentium MMX due to illegal instruction
On 2016-05-08 at 09:09, Neil Williams wrote: > On Sun, 08 May 2016 07:18:40 -0400 The Wanderer > wrote: > >> On 2016-05-08 at 03:45, Neil Williams wrote: >> >>> On Sun, 8 May 2016 00:51:57 +0200 Pierre Ynard >>> wrote: >> >> Even if running unstable, I would certainly expect that something >> which is known to break certain types of systems this badly would >> be announced at package install time, giving me a chance to cancel >> the install... > > It's unstable - I've been running unstable on my main development > laptop for ten years, most of the time that something has broken my > system, I've had to be the one to report it! Some of those bugs have > caused this level of breakage. Yes, that's part of the 'bargain' of running unstable. The difference is that, presumably, the fact that the change which led to that breakage would in fact so break things was not known in advance. I certainly do not expect such notification for every breakage which occurs in unstable. I was speaking only about cases where the fact that the breakage would occur was known in advance (which is the case here, because the breakage is an intentional feature removal), and where the breakage itself would be "bad enough" (in this case, essentially total). Off the top of my head, I can't actually think of another case where the breakage was both known in advance and expected to be total. If this case really is that unique, that would seem to be a point in favor of its being exceptional enough to warrant special notification measures. > It's also an issue of workload and whether there is a realistic > likelihood of that breakage. The expectation is that users of > unstable are not running production systems That expectation is perhaps not being properly communicated to the user base, then; as mentioned elsewhere, I have seen people who apparently know what they're doing advocating to people who apparently do not that tracking unstable is preferable to tracking testing. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Bug#823465: dpkg: Won't run at all on i586 Pentium MMX due to illegal instruction
On 2016-05-08 at 08:20, Marc Haber wrote: > On Sun, 08 May 2016 07:18:40 -0400, The Wanderer > wrote: > >> Even if running unstable, I would certainly expect that something >> which is known to break certain types of systems this badly would >> be announced at package install time, giving me a chance to cancel >> the install... and the more so considering that people keep talking >> about tracking sid as being a reasonable thing to do, although I >> myself decided years ago from experience that it was a bad idea. > > Tracking sid is a good idea if you can debug and fix breakages. If > you want to be warned for disruptions, use something that we > actually released. I agree, but I have seen people on debian-user advocating tracking sid by preference over testing as a recommended practice, even to the point of arguing against people who recommend otherwise. (Of whom I have seen fewer than I would have expected.) If the people who have been given this advice have been following it, there are people out there who certainly do not appear to be technically competent but who are nonetheless tracking sid. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Bug#823465: dpkg: Won't run at all on i586 Pentium MMX due to illegal instruction
On 2016-05-08 at 03:45, Neil Williams wrote: > On Sun, 8 May 2016 00:51:57 +0200 Pierre Ynard > wrote: >> I was thinking more along the lines of adding some central check >> in dpkg maybe, that detects the lack of i686 support and errors out >> on new, incompatible packages. Discriminating packages could be as >> simple as a by-passable check on the build/release date. But then >> this is a bit late to implement in advance. > > It's not about simply blocking installs - the package to be installed > is being upgraded for a reason, so blocking the install just blocks > the bug fix or blocks upgrades of other dependent packages, until > the binary is rebuilt in stable. That's why the advice is to move > this box to stable - ask for backports of any packages which need > updates from testing. > > You have four years to decide whether to replace this hardware or > continue running jessie without support. I read this suggestion as being less about this particular box, and more about preventing (other) people from having this breakage happen unexpectedly. In this particular case, it's already too late, after all. Even if running unstable, I would certainly expect that something which is known to break certain types of systems this badly would be announced at package install time, giving me a chance to cancel the install... and the more so considering that people keep talking about tracking sid as being a reasonable thing to do, although I myself decided years ago from experience that it was a bad idea. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Possible MBF: Packages depending on iceweasel but not firefox/firefox-esr
On 2016-03-20 at 06:43, Jakub Wilk wrote: > * Josh Triplett , 2016-03-18, 15:06: >> Firefox addon packages (xul-ext-*) typically have a Depends on >> iceweasel, sometimes with alternatives for icedove or other >> supported packages that can use the addon. With the switch to >> firefox and firefox-esr, iceweasel has become a transitional >> package depending on firefox-esr. The dependencies of these addon >> packages prevent installing only the firefox package and removing >> firefox-esr and the transitional iceweasel package. > > So let's fix Depends of the transitional package. No MBF is needed. I don't understand how that would help. It would let you install 'firefox-esr | firefox' to satisfy the dependency of xul-ext-foo, but it would not let you remove iceweasel without also removing xul-ext-foo. Now, one thing which seems like it _could_ fix this without requiring a MBF would be for firefox and firefox-esr to acquire 'Provides: iceweasel'. That seems like a misuse of the system to me, however, and a suboptimal solution at best. There is an argument to be made that firefox-esr should Provides: firefox (or that both should Provides: a single virtual package), or something along those lines, to avoid requiring packages to list both alternatives explicitly. I'm not sure that wouldn't have too many downsides to be a good approach, however. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: dbconfig-common: near future change in dependency stack
On 2016-01-30 at 08:49, Clint Byrum wrote: > Excerpts from The Wanderer's message of 2016-01-30 04:28:42 -0800: > >> On 2016-01-30 at 04:51, Paul Gevers wrote: >>> Actually, I don't think that is in scope of dbconfig-common. I >>> would rather expect that MariaDB would provide that >>> functionality. It is required for more packages and situations >>> than just those supported by dbconfig-common. >> >> Are there even cases where this is necessary? >> >> Within the last year, I encountered an unacceptable - but >> intentional - change in the MySQL client interface, so I removed >> the MySQL packages and installed the MariaDB ones. > > Which client interface would that be? libmysqlclient18 is still > provided by mysql, even if you install MariaDB. The one invoked with the command 'mysql'. The underlying library is still the same (though as far as I can see, the dependency chain from mariadb-client-core-10.0 to libmysqlclient18 only exists because libdbd-mysql-perl depends on the latter, so I'm not convinced that ), but the client itself behaves differently. The specific UI change which drove me away from "pure" MySQL was the change in line-editing library, away from readline, so that my habitual "jump around the line while editing the query" practices would no longer function - and, as far as I recall, there was no suitable replacement. I dug around for a while looking for a way to turn the readline behaviors back on, started digging into the process of building my own packages which revert to the old behavior, then discovered that MariaDB had not followed that change and decided to just migrate instead. >> My existing database was picked up and used without issues; the >> transition was, on that level, pretty much seamless as far as I >> recall. I might have needed to re-apply some configuration tweaks >> in different config files, but nothing more than that. > > This is a one-way trip as of MariaDB 10. MariaDB 5.5 was compatible > with MySQL 5.5 and allowed using the same on-disk files. But MySQL > may not know how to read all of the files produced by MariaDB 10+. So > I would not count on this working again in the future. They're truly > forks, and you will need to backup/restore to make this work. This is valuable to know for future reference, though I'm not sure I'm ever likely to need or want to migrate in that direction between the two; I was only still on MySQL rather than MariaDB out of inertia. Since the topic at hand was specifically migrating from MySQL to MariaDB, however, rather than bidirectional migration between the two, my question stands: are there cases where migration from MySQL to MariaDB needs to be done explicitly per-database? >> This seems to imply that either migration is not required, or >> MariaDB already performs the needed migration transparently. (Or >> else that I'm forgetting some part of the transition process, which >> is not impossible.) >> >> I can imagine that there could be cases where migration would be >> required, but I'm not aware of any, and it didn't even occur to me >> to expect that I might need to do any in my own case. I expected >> that the two would be seamlessly compatible on the database level, >> and that expectation seems to have been borne out. > > Yeah, that would be nice, but the reality is, code is only flowing > _away_ from MySQL at this point. MariaDB's changes don't go back > into MySQL. So the forks will just get further and further apart. That's more or less what I'd expect. It still seems possible that the "downstream" fork would retain input compatibility with the "upstream" parent, but certainly that's not guaranteed. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: dbconfig-common: near future change in dependency stack
On 2016-01-30 at 04:51, Paul Gevers wrote: > Hi Frederic-Emmanuel, > > On 30-01-16 09:30, PICCA Frederic-Emmanuel wrote: >> Do you know if dbconfig-common will integrate a way to switch from >> mysql to mariadb in the near futur. something whcih can help do the >> migration database from mysql to mariadb. > > Actually, I don't think that is in scope of dbconfig-common. I would > rather expect that MariaDB would provide that functionality. It is > required for more packages and situations than just those supported > by dbconfig-common. Are there even cases where this is necessary? Within the last year, I encountered an unacceptable - but intentional - change in the MySQL client interface, so I removed the MySQL packages and installed the MariaDB ones. My existing database was picked up and used without issues; the transition was, on that level, pretty much seamless as far as I recall. I might have needed to re-apply some configuration tweaks in different config files, but nothing more than that. This seems to imply that either migration is not required, or MariaDB already performs the needed migration transparently. (Or else that I'm forgetting some part of the transition process, which is not impossible.) I can imagine that there could be cases where migration would be required, but I'm not aware of any, and it didn't even occur to me to expect that I might need to do any in my own case. I expected that the two would be seamlessly compatible on the database level, and that expectation seems to have been borne out. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Removing sysV init files
On 2016-01-15 at 09:45, Alec Leamas wrote: > On 15/01/16 14:13, Dmitrii Kashin wrote: > >> Alec Leamas writes: >> >>> Dear list, >>> Given all this: would it be OK to drop the sysV files in a >>> stretch update? >> >> I suppose it's not okay, because you'll get a lot of bug reports >> from non-linux based debian distributions. And if it's not your >> business, and you don't support sysv scripts, then it will >> eventually become a problem for developers of these distributions. >> >> I wanna remind that systemd as the default is an experiment. It can >> be finished in a while. So it's important to safe the support for >> other init systems. While I agree with the sentiment, I'm not sure I've heard that choosing systemd as default was an "experiment" before now, at least any more than any Debian choice is an experiment (in that the project can decide to switch away from it if it doesn't work out well). >> Btw, I'm a user of Debian Jessie, and I see then now Debian keep >> an ability to work without systemd. I'd like it to be so in the >> future. > > So, here is three things: > > Support for non-linux based debian distributions. Perhaps this could > be handled by packing current scripts in /usr/share/doc, so they are > available for downstream packaging? Besides that, what says policy > decisions on this issue? It's not only about downstreams. What about e.g. Debian-kFreeBSD, or Debian-Hurd? Both are theoretically official Debian, as far as I understand matters, rather than being downstream distros - but neither one is supported by systemd. > Support for users not using systemd. I understand that such users > will be unhappy without the scripts - but am I obliged under current > policy decisions to maintain this configuration? My understanding from the past debates is that you're not obliged to maintain sysvinit scripts, but that if other people want to do the work and send in patches to add / update / maintain such scripts, you don't get to reject them - or at least not on the grounds that sysvinit is not supported. That would seem to imply, in turn, that you shouldn't drop existing sysvinit scripts from the package, unless they're known to already be broken badly enough that not having any would be an improvement (although I don't think I've seen this specifically addressed in past discussions). You wouldn't be obliged to continue to maintain and update them, however, and IMO - in the absence of someone who _is_ doing that - you'd be fine to put in a warning that using them is unsupported and not recommended. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Bug#809014: ITP: chewing-editor -- libchewing user phrase editor
On 2015-12-27 at 00:38, ChangZhuo Chen (陳昌倬) wrote: > On Sat, Dec 26, 2015 at 09:24:08AM +, Wookey wrote: > >> I am none the wiser what this software does as I don't know what a >> 'chewing user phrase' is. I think this description should be expanded a >> little so it makes sense to a general reader. >> >> Also the English is clearly written as a foriegn language. I assume >> this is more correct (but not knowing what these 'phrases' are, or >> how/why they affect 'input performance' it's hard to be sure): > > Thanks for the suggestion. I will update the description as following: > > > user dictionary editor for chewing input method > > chewing-editor is a cross platform user dictionary edtiro for chewing > input method. It provides an easy way to customize user dictionary so > that chewing input method can take advantage of the user dictionary and > provide a better input experience. For correct grammar, this should probably refer to "the chewing input method" instead of just to "chewing input method". Similarly, it should probably be "customize the user dictionary" instead of "customize user dictionary". The result of those changes isn't ideal, but it's adequate - and fixing things up further would be me rewriting things on my own initiative, rather than just pointing out corrections. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Upcoming version of apt-file - using apt-acquire and incompatibilities
On 2015-12-06 at 18:23, Russ Allbery wrote: > The Wanderer writes: > >> I'm not sure I'm happy about such an important change in the >> behavior of the core binary of one package being (able to be) made >> by an update to a completely different package, and I certainly >> wouldn't have been happy to discover it after the fact by seeing >> 'apt-get update' do something unexpected - but there's not much I >> can do about it... > > I'm guessing you weren't previously familiar with apt's really nice > hook system? It's much more natural to expect this sort of thing to > be possible if you've run across the hooks before, and if you've not > looked at them, it might be worth your time at some point. You can > do all sorts of pretty awesome stuff. That's one of the ways > etckeeper integrates with apt, for instance. I was aware of the existence of such a system, though only from being aware of apt-listbugs and apt-listchanges, which hook in at a very different stage of the process and work in what looks like a different way; I just didn't know its reach could go anywhere near that far. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Upcoming version of apt-file - using apt-acquire and incompatibilities
On 2015-12-06 at 15:30, Russ Allbery wrote: > The Wanderer writes: > >> $ apt-cache policy apt-file >> apt-file: >> Installed: 2.5.4 >> Candidate: 2.5.4 >> Version table: >> *** 2.5.4 0 >> 500 http://ftp.us.debian.org/debian/ stable/main amd64 Packages >> 500 http://ftp.us.debian.org/debian/ testing/main amd64 Packages >> 100 /var/lib/dpkg/status > >> So my inference at this point is that in testing and stable, 'apt-get >> update' (and presumably 'apt update') does not update the apt-file >> index, but in experimental and possibly sid it does. > >> IOW, this is not only new since I noticed the above, but new since >> _now_. > > Yes... that's what the words in the subject header of this thread mean? > The word "upcoming" was important. :) Yes, I know. I think the confusion here arose from the simple facts that A: it would not have occurred to me to consider that a change in the apt-file package could introduce a change in the behavior of a binary (apt) shipped in a separate package, and B: no mention of an upcoming change to that separate package had been made. Based on that, I assumed that in order for 'apt-file update' to become a wrapper around 'apt update', the "update both indices" behavior would need to already exist in apt - and therefore that that behavior exists in _current_ apt. Since I had not seen it in apt-get, this supported my existing impression that apt and apt-get are meaningfully different. Starting from that point, Niels' response to my initial comment seemed contradictory vs. my own observations; if apt does this, and apt uses the same code as apt-get, but apt-get does not do this, then there's a mismatch somewhere. Jakub pointed out (implicitly in passing) that this change is apparently in fact being made purely by way of a config file in the apt-file package, which presumably apt and apt-get already know how to read and handle. I missed the implications on the way by (in fact, it took me three drafts of this reply to fully work them out), and responded to the question which he actually asked. I'm not sure I'm happy about such an important change in the behavior of the core binary of one package being (able to be) made by an update to a completely different package, and I certainly wouldn't have been happy to discover it after the fact by seeing 'apt-get update' do something unexpected - but there's not much I can do about it... -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Upcoming version of apt-file - using apt-acquire and incompatibilities
On 2015-12-06 at 11:46, Jakub Wilk wrote: > * The Wanderer , 2015-12-06, 08:50: > >> Er... the entire reason I started running 'apt-file update' in the >> first place is because running 'apt-get update' was not, or did >> not appear to be, updating the index which was used by apt-file. > > Quick sanity check: do you have apt-file (>= 3) installed? Because > this is the package that ships the configuration file for APT that > causes apt(-get) to download Contents-*. $ apt-cache policy apt-file apt-file: Installed: 2.5.4 Candidate: 2.5.4 Version table: *** 2.5.4 0 500 http://ftp.us.debian.org/debian/ stable/main amd64 Packages 500 http://ftp.us.debian.org/debian/ testing/main amd64 Packages 100 /var/lib/dpkg/status So my inference at this point is that in testing and stable, 'apt-get update' (and presumably 'apt update') does not update the apt-file index, but in experimental and possibly sid it does. IOW, this is not only new since I noticed the above, but new since _now_. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Upcoming version of apt-file - using apt-acquire and incompatibilities
On 2015-12-06 at 07:01, David Kalnischkies wrote: > On Sat, Dec 05, 2015 at 07:58:07AM -0500, The Wanderer wrote: >> Will it still be possible to update just the apt-file index, >> separately from updating the main package index? I see no >> indication in the current apt(8) man page of a way to tell apt to >> do this. > > You can't update individual indexes at the moment. The question is > why you would want to as from my point of view that was a pretty > annoying technical detail that I had to run two (or three [debtags] > or more) commands to get all the metadata. Probably because I forgot > at least one or some data was newer/older than other parts… so what > is the usecase exactly, maybe we can come up with something then There's no real practical use case for me at the moment, aside from the principle of retaining flexibility and user control. There are a few not-practical cases, though nothing I'm managing to remember well enough to articulate, but in large part this is a matter of "I've gotten used to being able to do it, so even though it would/will be nice to not have to do it, I still want the option of doing it if I so choose". > (as I am sightly lying, it is actually possible – just not very > accessible for a user and it would have issues so I am not going to > say how here) In public, where it can be discovered later by people who won't know or be in a position to even judge (much less handle) those issues, you mean? I can understand that, but I'd like to know how it would be done (and what the issues might be, of course), so if there's a chance to go over that elsewhere - e.g. by direct mail - at some point I'd be interested. >> I don't use 'apt update', but rather 'apt-get update', paired with >> a separate 'apt-file update'. While unifying the two commands would >> be useful for those who use apt, it would also seem to leave those >> who don't with at most three options: switch to apt, stop updating >> the apt-file index, or deal with redundant updates to the package >> index (which might quality as "switch to apt" in practice). > > There is no fundamental difference between apt and apt-get, they are > not only maintained by the very same people, but also use the same > data and code – the difference is just in a few options which have a > different default value (try "apt-config dump Binary::apt" for a > list). > > So, use whatever you prefer and use something different a second > later. Er... the entire reason I started running 'apt-file update' in the first place is because running 'apt-get update' was not, or did not appear to be, updating the index which was used by apt-file. (Now that I've gotten used to it, I have occasionally taken advantage of the ability to do one but not the other.) So if 'apt-get update' now updates the apt-file index as well, A: this appears to be new since that time, and B: it is far from obvious at runtime, since at minimum it certainly does not display similar output to what I see from 'apt-file update'. If that's not what you mean, then I fail to see how this is a response to what I wrote... -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Upcoming version of apt-file - using apt-acquire and incompatibilities
On 2015-12-05 at 07:39, Niels Thykier wrote: > Hi, > > In the new version of apt-file (currently in experimental), we have > changed/removed some features that will affect some packages. Packages > listed below are BCC'ed to this mail. > > Notably: > * "apt-file update" will become a thin call to "apt update" >- live-build uses this in a hook Will it still be possible to update just the apt-file index, separately from updating the main package index? I see no indication in the current apt(8) man page of a way to tell apt to do this. I don't use 'apt update', but rather 'apt-get update', paired with a separate 'apt-file update'. While unifying the two commands would be useful for those who use apt, it would also seem to leave those who don't with at most three options: switch to apt, stop updating the apt-file index, or deal with redundant updates to the package index (which might quality as "switch to apt" in practice). -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Porting DKMS package from ubuntu to debian shows compilation errors
On 2015-09-27 at 10:43, Paul Wise wrote: > On Sun, Sep 27, 2015 at 10:44 AM, laalaa wrote: > >> In file included from >> /var/lib/dkms/oem-audio-i915-baytrail/0.20150605/build/i915/i915_drv.c:33:0: >> /var/lib/dkms/oem-audio-i915-baytrail/0.20150605/build/i915/i915_drv.h:277:2: >> error: unknown type name ‘drm_local_map_t’ >> drm_local_map_t *sarea; >> ^ > > Looks like the code you are compiling isn't compatible with the > version of the Linux kernel that you are compiling against. I would > try to find a newer version of the code or report this issue to the > person who is responsible for maintaining oem-audio-i915-baytrail. Or possibly find an _older_ version of the code; it doesn't seem impossible that this module might have been updated for kernel changes which are more recent than what's in kernel 3.18.21. In fact, that seems reasonably likely. I have headers for 4.0.0-2, 4.1.0-1, and 4.1.0-2 installed, and they all define drm_local_map_t in include/drm/drm_legacy.h; if kernel 3.18.21 defines it elsewhere (such that the includes in this module don't find it) or doesn't define it, that would explain the observed behavior. Unfortunately I don't have immediate access to a set of headers for the 3.18-era kernel, so I can't easily check that myself, but it shouldn't be hard for you to check it on your build machine. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: DAK Commands for Bikesheds
On 2015-09-17 at 15:04, Robert Edmonds wrote:
> Wookey wrote:
>
>> +++ Raphael Hertzog [2015-09-17 14:41 +0200]:
>>> Please don't call this feature "Bikesheds" and don't hardcode
>>> this naming in the suggested API. It was funny during one Debconf
>>> talk... but it won't be funny in the long term.
>>
>> It wasn't supposed to be a joke. Bikeshed is an appropriate name,
>> in the unix tradition of mildly amusing/punny names.
>
> Which tradition would that be?
>
> Out of the few hundred or so Unix [0] and GNU [1] commands listed on
> Wikipedia, the only vaguely amusing/punning names I can find are tac
> ("cat" backwards) and pinky (a lightweight "finger").
There's also nano; it's named for similarity to pico, which I believe
was named as a shortening of "pine composer". pine in its turn was (I
believe) named for similarity to elm, which was an abbreviation for
something I forget. Both the names pine and nano are "amusing/punny" in
that sense.
Also, the GIMP is a play on words of its own - and for that matter, the
recursive acronym "GNU" is a similar piece of wordplay.
I concur that this sort of wordplay in naming is a *nix tradition;
however, I withhold comment as to whether the name "bikeshed" is
appropriate in this case, as the first I remember hearing about them is
this thread and I don't know enough about the context to form a
defensible opinion.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
