Re: proposal: Hybrid network stack for Trixie
Lukas Märdian writes: > On 23.09.24 12:27, Ansgar 🙀 wrote: > >> So on desktop installations including NetworkManager, netplan will >> be >> configured to do nothing? Why install netplan at all on desktop systems >> then? > > Because it allows to add configuration in a way that is common with server, > cloud > and other instances of Debian. It's not about enforcing this, So using netplan is optional. The system will work as before without netplan. netplan won't replace any packages. NM, systemd-networkd or ifupdown* are still required with or without netplan. What are we discussing here, actually? Making someones pet project default to increase the install count? No thanks. That's bloat. Bjørn
Re: Community survey on network stack for Trixie
Lukas Märdian writes: > But in the end we don't want to bloat our base-installation with > NetworkManager and systemd-networkd is not fit to cover the desktop/laptop > usecase. So why not put some glue around it, to make it all feel coherent, > without limiting anybody in their decision to choose whatever stack they > like? We have that choice without netplan too. Should users have a choice wrt netplan? Don't they already? Is a base-installation with netplan and NetworkManager less "bloated" than an installation with only NetworkManager? Will netplan and systemd-networkd cover the desktop/laptop usecase, or do you still need NetworkManager for that? Exactly what problem are you solving here? Bjørn
Re: ifupdown maintenance
Matthias Urlichs writes: > On 09.07.24 12:27, Bjørn Mork wrote: >> Run user scripts on up/down events. That's a huge blank spot in >> systemd-networkd. And by design, so it's really not fixable. > > Well, I've been apt-purging ifupdown for almost a decade by now and > didn't yet miss any of it. > > > You can think whether that script is still required; maybe > systemd-networkd / -resolved can do it for you. > > Or you can monitor systemd's and systemd-networkd's dbus for network > devices appearing (or vanishing) and run the requisite script. > > Or you can use udev rules. > > Or you can tell a unit to run only when a specific network interface > is present. > > Or you can use NM and its script dispatcher instead. > > Or, well, you can of course continue to use ifupdown if none of the > above work for you. But that doesn't mean ifupdown should be the > default IMHO. FWIW, I agree with all that. Just tried to point out that automatic conversion will be hard. And probably not very useful. Many of the old ifupdown configs should be redone and re-thought rather than reimplemented. There are most likely better ways to do much of it, using the new possibilities you get with NM and systemd-networkd. Bjørn
Re: ifupdown maintenance
Matthias Urlichs writes: >> Agreed: either it's drop-in compatible or we may as well switch the >> default to NM and/or systemd-networkd. > > Well, here's a heretical thought: why don't we do that anyway, at > least for new installations? > > Somebody could even write a converter. Shouldn't be that difficult, > AFAIK there's nothing ifupdown can do that systemd[-networkd] can't. Run user scripts on up/down events. That's a huge blank spot in systemd-networkd. And by design, so it's really not fixable. Sure, we do have networkd-dispatcher but it's not quite the same. And "Somebody" would have to do a really huge job to create a complete automatic converter. I don't think that's worth the effort. But it's of course up to "Somebody" to decide how they want to spend their resources. Bjørn
Re: Linking coreutils against OpenSSL
Luca Boccassi writes: > If we want to start nitpicking, then let's be exact: 0.61% of popcon. > Whether that qualifies as "plenty" we'll leave as an exercise for the > readers. I wonder if this sort of arrogant "don't care about minorities" attitude will ever stop? Was sort of hoping that things would quiet down when everyone just gave up on the systemd and usr-merge crazyness. But it seems the bullies continue on and on and on and on. I guess those 0.61% are run bt the most valuable Debian users out there. I'm sorry to not be one of them, but that's the way things have become. Not by choice. Bjørn
Re: snapshot.d.o has been in a bad state for several months
"Theodore Ts'o" writes: > I was curious about this, since I rely on snapshots.debian.org in > order to create repeatable builds for a file system test appliance, so > I started digging a bit. Looking at the debian-bugs pseudo-package > "snapshot.debian.org": > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=snapshot.debian.org > > the maintainer is listed as: > > "snapshot.debian.org Team " > > But according to lists.debian.org, "debian-shaphots" is a dead list, "debian-shaphots" != "debian-shapshot" :-) https://lists.debian.org/debian-snapshot/ Bjørn
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
nick black writes: > what > does NetworkManager offer that makes it superior to > systemd-networkd on the desktop I don't know what systemd-networkd has to offer in this regard, but for laptop usage I'm personally fond of the ModemManager integration along with multihoming policies (eth0 preferred over wlan0 preferred over wwan0 by default). For the same reason I believe conman should not be default on any hardware with a built-in modem, regardless of desktop choice. For servers I agree with others here - I'm slowly migrating to systemd-networkd. Makes stuff like DHCPv6-PD much easier to manage for example. I've been a happy ifupdown user for ages, but now I believe it's time to move on... A standalone dhcp client is still important to me for one specific use case: testing and debugging of DHCP services. Been using the ISC client a lot for this, both for IPv4 and for different DHCPv6 modes. I guess the busybox client is a good enough replacement for v4. Not sure about DHCPv6. The advantages of the ISC client for this use case has been the terminal debug output and the scripting abilities, where you also could use "/usr/bin/env" as "script" to dump all the vars. Bjørn
Re: booststrapping /usr-merged systems
Steve McIntyre writes: > Raphaël Hertzog wrote: >> >>In the same spirit, I'd like to throw an idea... could we decide that >>base-files is the first package to be configured as part of the bootstrap >>protocol and change base-files maintainer's scripts into statically linked >>executables so that they can work even if we don't have the library loader >>on the ABI-compliant path? > > What exactly do you mean here? You know that even a statically linked > executable needs an interpreter defined in the ELF header? Maybe I'm missing something, but can't you code a different interpreter path insto such a special purpuse script? #!/usr/lib/x86_64-linux-gnu/ld-2.31.so /usr/bin/dash echo foo [ -e /lib ] || /usr/lib/x86_64-linux-gnu/ld-2.31.so /usr/bin/ln -s /usr/lib /lib or whatever? Bjørn
Re: booststrapping /usr-merged systems
Marco d'Itri writes: > as we all know every Debian maintainer can veto any systemic changes > that they do not like. I don't think qusr-merge would not have happened if this was true. And I believe you know that very well. I find your remark disrespectful. And I'm trying hard to assume good faith here. Please help me. What are you trying to achieve by it? Was it meant as a joke? If so, then it was a bit misplaced I'm afraid. Maybe you should re-read https://www.debian.org/code_of_conduct ? Bjørn
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)
Ansgar writes: > On Fri, 2023-05-19 at 20:57 +0200, Bjørn Mork wrote: >> Hmm. I find the netboot installer archives very useful for rescue >> purposes. This sometimes involves PC hardware too old for amd64. I PXE >> booted a 20+ year old laptop with no DVD/CD drive (Compaq Evo N410c - CD >> drive was part of the optional docking station) using a bullseye >> netboot.tar not long ago. > > You can keep using the bullseye netboot.tar for the next 20+ years to > rescue boot an ancient system, copy the data off of it, and then > responsibly dispose the system. That won't work, will it? netboot must match the kernel version in the archive to be useful. Or am I missing something? > I don't think this is a good argument to keep generating i386 install > media. Maybe not. Just wanted to mention the use case so it can be considered. I understand that it might not justify the resources required. Bjørn
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)
Steve McIntyre writes: > I had been thinking about doing similar for installer images too, but > with other work going on too I think it got too late in the cycle to > make that change. My plan is therefore to ship i386 installer images > for bookworm as normal (including bookworm point releases going > forwards), but to disable those builds for testing/trixie ~immediately > after the release. Hmm. I find the netboot installer archives very useful for rescue purposes. This sometimes involves PC hardware too old for amd64. I PXE booted a 20+ year old laptop with no DVD/CD drive (Compaq Evo N410c - CD drive was part of the optional docking station) using a bullseye netboot.tar not long ago. Not a major thing, but if you're going to keep most of i386 anyway... Bjørn
Re: transition to usrmerge to start around 2022-09-15 (next Thursday)
Luca Boccassi writes: > Nothing was ignored. In the spirit of good faith I'll assume you meant "Nothing new was ignored". It's a fact that you are ignoring a few issues caused by usrmerge. This is thoroughly documented in the BTS. Arrogance is not on the bug list, but maybe it should be? It's definitely something Debian will have to work on before releasing with usrmerge in the current state. usrmerge adds bugs which you so far have been unable to fix. That's nothing to be ashamed of. Just try to be honest about it. I assume that you plan to fix the bugs before the release. Note that the CTTE did not request the addition of any bugs, or make any exceptions for the usrmerge package. What to do about usrmerge if it conflicts with other goals is not decided yet. So if you don't want another round of pointless discussions, then I suggest that you start working on those bugs now. That's the smart thing to do if you want to make *sure* usrmerge is part of the release. If there is no conflict between release goals, then there will be no need for a discussion. I find it quite disappointing to read https://bugs.debian.org/848622 . I don't know if it is arrogance or ignorance, but this bug is undoubtedly caused by usrmerge: frtest2:~# ls -l /usr/bin/bash -rwxr-xr-x 1 root root 1283864 Aug 25 16:03 /usr/bin/bash frtest2:~# dpkg -S /usr/bin/bash dpkg-query: no path found matching pattern /usr/bin/bash Pointing at other maintainers/packages to fix your bugs is anti-social. Don't force Debian decide whether the usrmerge bugs should be accepted in the next release. Just fix them. The alternative is ugly. And I'm not thinking about the actual bugs, but about the discussion... It's fine to oversell the advantages of usrmerge. It's not fine to try to hide the disadvantages. Bjørn
Re: adduser default for sgid home directories
Philipp Kern writes: > On 25.07.22 08:46, Bjørn Mork wrote: >> Matt Barry writes: >>>> - why has a change been made >>> >>> I think this is explained in excruciating detail. The short version >>> (from NEWS): >>> >>> "mode 0700 provides both the most secure, unsurprising default" > [...] >> And the claim that this is "most unsurprising" (less surprising?) is >> obviously false. "No change" is always less surprising than any change, >> whatever the rationale is. > > It can also be unsurprising from an end-user's perspective. For > someone new to the system. So that line of argument does not really > hold. True. Good point. I was reading this as "unsuprising to the reader (system operator)", but I see that it could mean "unsusprising to the system users". Which would make more sense. Is there a limit to the size of these entries which makes it hard to be more precise? Bjørn
Re: adduser default for sgid home directories
Matt Barry writes: >> - why has a change been made > > I think this is explained in excruciating detail. The short version > (from NEWS): > > "mode 0700 provides both the most secure, unsurprising default" This is a self-referencing explanation. It provides no value. It's only good if you already understand (and agree) that 0700 is more secure. And the claim that this is "most unsurprising" (less surprising?) is obviously false. "No change" is always less surprising than any change, whatever the rationale is. Bjørn
Re: What to do with merged /usr and dpkg-fsys-usrunmess
Andrey Rahmatullin writes: > On Wed, Apr 06, 2022 at 04:02:23PM +0200, Bjørn Mork wrote: >> > Sorry, blame the dpkg maintainer. >> >> Is that how we discuss technical issues around here? > This is not a technical issue. Ah, sorry. I mistook this for the "Discussion about technical development topics" list. My fault Bjørn
Re: What to do with merged /usr and dpkg-fsys-usrunmess
Marco d'Itri writes: > Sorry, blame the dpkg maintainer. Is that how we discuss technical issues around here? Bjørn
Re: Gmail bounce unauthenticated @debian.org addresses
"LeJacq, Jean Pierre" writes: > There are standard best practices for forwarding support in SPF. > > http://www.open-spf.org/Best_Practices/Forwarding/ Well, if it only was that simple. There is NO working SRS software/example config for sendmail in Debian or anywhere else AFAICS. The only thing we have is the python3-srs packages, which are still full of python2 specific code. None of the included tools even run on bullseye. For example: bjorn@canardo:~$ /usr/bin/srs2envtol Traceback (most recent call last): File "/usr/bin/srs2envtol", line 14, in from ConfigParser import ConfigParser, DuplicateSectionError ModuleNotFoundError: No module named 'ConfigParser' bjorn@canardo:~$ dpkg -S /usr/bin/srs2envtol pysrs-bin: /usr/bin/srs2envtol bjorn@canardo:~$ apt-cache policy pysrs-bin pysrs-bin: Installed: 1.0.3-2 Candidate: 1.0.3-2 Version table: *** 1.0.3-2 700 700 http://deb.debian.org/debian bullseye/main amd64 Packages 100 /var/lib/dpkg/status (yes, I could fix that and the remaining issues - but that's not the point) IMHO, modifying postsrsd looks like a much better alternative if I were to write something. Should be pretty easy to make it optionally use the sendmail socketmap protocol instead of the postfix tcp_table protocol. Or alternatively just write a simple proxy protocol translater. Then it could be plugged right into the example sendmail config from pysrs. But as have been the result each time I've considered SRS: I got bored with it long before I got it running. Why do I care whether google can send a bounce back? So I've just added owner-aliases for all my forwarded accounts (only a handful), pointing to a /dev/null address. That does it for me. SRS and SPF can continue to burn in the hell where it was invented. Stay tuned for the next episode of Mail Server Frustrations, where we'll look at Exim and mixed TLS (port 465) and STARTTLS (port 587) submission. Bjørn
Re: The future of src:ntp
Bernhard Schmidt writes: > - Since NTS leverages X.509, how does it work with a broken clock on > boot that is ticking outside of the certificate validity period? I don't know how it is intended to work, but it seems pretty obvious that NTS certificate validation must ignore the validity period. If you have a validating DNS resolver with correct time, then you might replace it with DANE validation (i.e if the certificate matches the current DNS TLSA record then it is valid regardless of current time). But I don't know if you can make that a requirement. Bjørn
Re: etc/resolvconf/update-libc.d/ equivalent for systemd-resolved
Scott Kitterman writes: > I believe I can solve this problem by adding Recommends: resolvconf if that's > the only way. I had hoped there would be some "modern" way to do it from > within Debian's default package set. Funny. That seems to have been the solution to this bug almost 20 years ago too: https://bugs.debian.org/154669 Bjørn
Re: merged-/usr transition: debconf or not?
Michael Biebl writes: > Am 17.11.2021 um 19:57 schrieb Sam Hartman: >> The question is whether we ever get to a place where people can update >> files in a package currently installed to /bin/foo and instead install >> them to /usr/bin/foo. >> We have a consensus that dpkg bugs make that a bad idea. > > Is that really so? If I'm not mistaken, the problematic part was > moving files from / to /usr and at the same time moving files between > packages. So doing that at the same time can be problematic. If that > would affect many packages is another question. > > AIUI simply moving files from / to /usr within the same package is not > problematic. Won't you then end up with a package which cannot be split for the next two releases? Maybe not a big problem, but I think it will be so hard to keep track of that it's better to not move the files. Bjørn
Re: Q: Use https for {deb,security}.debian.org by default
Jeremy Stanley writes: > While this does complicate it, a snooping party can still know the > site they're connecting to via SNI happening unencrypted, I believe this can be fixed with TLS 1.3? > and packet sizes/pacing likely give away which pages or files are > being retrieved based on their length. Yes, probably looking into territory where you'd not want to directly access any public service at all here.. > And that's not even getting into > how "trusted" certificate authorities give away certificates for any > hostname if your MitM knows the right people, Debian is among the few who publish TLSA records (DANE). Which is still pretty useless for normal web srvices since the major browser vendors refuse to support it. But TLSA validation could easily be implemented in apt-transport-https. Maybe it is? That would prevent this problem. > and CDNs are now in > the business of snooping on everyone's traffic for sites where they > handle SSL/TLS termination. HTTPS as deployed on the open Internet > is a sip of security with several gulps of theater. Not much to do if you don't trust your own servers, whether they are CDN frontends or whatever. Bjørn
Re: a proper-unix meta package (Re: Proposal: plocate as standard for bookworm)
Adam Borowski writes: > On Wed, Feb 10, 2021 at 12:21:36PM +, Holger Levsen wrote: >> On Wed, Feb 10, 2021 at 01:05:04PM +0100, Bjørn Mork wrote: >> > I happen to disagree. To me this is yet another step away from being a >> > proper Unix system - to something else. Which would be fine if it moved >> > us forward. >> >> As it's 2021 and 99% of the Linux user base has no idea what UNIX (or Linux) >> is, maybe it's time for a src:proper-unix-system package for those who care? > > Define "proper Unix"... The definition depends on whether you are a longhair or shorthair. Bjørn
Re: Proposal: plocate as standard for bookworm
Marvin Renich writes: > * Steinar H. Gunderson [210209 14:27]: >> On Tue, Feb 09, 2021 at 08:53:10PM +0200, Adrian Bunk wrote: >> > And there are now also many non-technical Linux users who have never >> > used a shell. >> >> Well, why do we include netcat, telnet or hdparm? lsof? pciutils? >> traceroute? host? All of these are irrelevant for a non-technical >> non-shell user, yet a fairly common part of a Linux installation. > > These have come to be expected to be on a typical Linux system by almost > every technically-knowledgeable Linux user. Locate does not satisfy > that criterion, and I think the dissension in this thread is evidence of > that. This is subjective. I don't think arguing about the expectations of "every technically-knowledgeable Linux user" is going to bring the discussion anywhere. FWIW, locate was "always" there. Before Linux and before PCI. See https://en.wikipedia.org/wiki/Locate_(Unix). > However, I agree with others here that anyone who wants a locate > implementation will know how to find all the packages with "locate" in > their names and plocate looks to me, from the descriptions, to be the > best choice. I don't think it deserves "Priority: standard". I happen to disagree. To me this is yet another step away from being a proper Unix system - to something else. Which would be fine if it moved us forward. But removing functionality can hardly be argued to be a move in the forward direction? Sure, I can install mlocate or plocate. But it's the kind of tool you expect to be present, with an uptodate database, when you need it. The database makes locate different from all the other tools you mention. I also use Linux systems I don't admininstrate. I'd hate to have to ask the admin for every basic Unix tool I need. Some of the standard tools you mention are only relevant for admins. Those don't need to be standard. But the ones that are relevant for users should be. Bjørn
Re: Fixed release dates are hurting quality
John Paul Adrian Glaubitz writes: > If the packages in question are essential, then these packages should get a > proper > maintainer with a maintenance release first before the freeze kicks in. How does that happen? Bjørn
Re: Making Debian available
There is no one proposing that non-free should be mandatory. The original topic was whether it should be possible to install Debian at all, noting that there are situations where this now is so difficult that it will be percevied as "impossible" by some users. I believe it is an undisputed fact that there are computers which need non-free firmware to access the Internet. There is most likely also a group of potentional Debian users who would prefer to use WiFi for installation even if they have other options. Should computers/users with WiFi-only Internet access be supported by Debian? I'll assume the answer is yes. After all, Debian is "The universal operating system". It has been documented in this thread it is possible to install Debian on such systems. But the images which allow this without additional steps is well hidden. And the procedure supported the default images is so complicated that even expert longtime Debian users have a hard time using it. The procedure would obviously be simpler if the firmware was included in the default installation image. I don't think there is any dispute so far? So we have established an upside. The dispute seems to be about the downside. Is there one? The firmware we are discussing is avaliable to every Debian user with Internet access. Whether it is in the installation image or not does not change that. Availabilty does not imply that the firmware must be used. The installer can still ask about using "additional non-free drivers" for installation. The difference is that the user will have an actual choice. As mentioned before, the use of non-free for the installed system does not depend on this at all. And IMHO, it should be left as an unrelated question. Even allowing temporary usage of non-free firmware to install Debian on a system with only free software. No choice is taken from the user. What we are left with is users who are offended by the mere existence of non-free binaries on a Debian image, and who see this as significantly worse than the non-free firmware in their NIC, SSD, EC, CPU etc. And worse than the existence of the same firmware on the Internet, including any Debian morror serving non-free. These users, if any, could be served by a non-default Debian image where the non-free firmware has been removed. Does that downside even compare to the upside? Are there any users who are offended by the mere existence of a file in an installation image they are free to avoid? Did I miss something? Debian is "The universal operating system". The implications are clear in my opinion. Bjørn
Re: Making Debian available
Steve McIntyre writes: > However, in the latter case Debian has shipped non-free stuff. That is > a big shift in our position. Don't get me wrong: I'm not saying this > is an impossible place for us to go to. But before we do that we > should have an open and honest debate about it. I absolutely 100% agree to that! Bjørn
Re: Making Debian available
Steve McIntyre writes: > Marc Haber wrote: >> >>I was not aware of that feature. It is good to have that, but I would >>be embarrassed to seriously suggest this way because we can't manage >>to get WLAN working in the installer for political reasons. > > Are we seriously just going to describe our Free Software goals as > "political reasons"? Should we just abandon them? FWIW, I did not read Marc that way. Somehow, the Free Software goals have been interpreted to mean that there is a difference in "free" between firmware on device internal flash and firmware on host ssd. This makes no sense from a technical point of view. Which makes the interpretation political if we assume that the decision is made by otherwise sane people ignoring technical arguments. No one has described the Free Software goals as "political reasons". Perosnally, I believe the current Debian handling of firmware works against the Free Software goals. That should worry those who care more about those goals than the political reasons for disliking some types of hardware. Bjørn
Re: Making Debian available
Marc Haber writes: > My workaround is to plug in a network cable for installation. But > alas, I have up to now been able to avoid hardware without built-in > Ethernet. I guess that many USB Ethernet interfaces will work out of > the box without non-free, right? Yes, even integrated LTE/5G modems could "work out of the box without non-free", if the GPLd userspace tools were included with the installer. This demonstrates how ridiculous the WiFi firmware restrictons are. All these USB devices work only because they come with firmware on a largish flash. In the LTE modem case, the firmware is a complete source-less Linux installation with big binary-only blobs for the radio/signal processors. This is obviously not more "free" than downloading a firmware blob for the processor in the WiFi module would be. I believe it's about time Debian gets rid of the double standard. Just admit that non-free firmware is required to run Debian on any modern system. Making it hard to install Debian over WiFi does not change anything. It just makes it hard to install Debian. Bjørn
Re: debian names
Jonas Smedegaard writes: > I would consider it highly unlikely that (Disney would claim and a court > would agree with them, that) Pixar customers could confuse some Pixar > products with a Debian release. I believe Disney lawyers are world famous for their ability to construct a legal problem from thin air. Or maybe they don't even need air if it is licensed? Evil tongues have claimed that Carl Barks modelled Sylvester J. Sharky after one or more Disney lawyer: https://en.wikipedia.org/wiki/List_of_Donald_Duck_universe_characters#Lawyer_Sharky In any case, the problem will be solved when Disney buys Debian. That's how The Simpsons finally got away with all their Disney jokes. Or you might want to reference Don Rosas drawing of "the hardest, toughest, most impervious substances known to mankind" at the bottom of https://duck.neamar.fr/DUCK/the_universal_solvent Bjørn
Re: Nitrokey for DDs
Zlatan Todorić writes: > In that regard, if DDs find Nitrokey interesting, I have contact with > their founder and we could negotiate discount(s) on their products and > also pursue similar effect as with Peertube - we (potentially) get > what some (all?) DDs need while we help them grow as independent open > source vendor. I'd like to add that they are offering free "Nitrokey Start" to kernel developers, in co-operation with the Linux Foundation. I assume there is some overlap with DDs there. All you need to qualify is an email address in MAINTAINERS. See https://www.linux.com/news/nitrokey-digital-tokens-linux-kernel-developers/ for more info. Bjørn
Re: RFC: Replacing vim-tiny with nano in essential packages
"Theodore Y. Ts'o" writes: > I've always considered /bin/ed the most basic system administration > tool, since it doesn't require a working terminal or termcap entry. > It works even if you are using an ASR-33 teletype. :-) > > And at least for me, I find /bin/ed much more user friendly than vi, > since it doesn't have as modal of a UI as vi. (Vi has 3 modes, ed has > only 2.) > > /bin/ed is also *much* smaller than even busybox. And of course, it *is* the standard text editor. https://www.gnu.org/fun/jokes/ed-msg.en.html Bjørn
Re: pager and upgrades
Thomas Goirand writes: > without a pager installed. Is that really possible? AFAICS, /bin/more is part of util-linux which is essential. So you will always have at least one pager installed. But something might have messed up the alternatives symlinks. Falling back to /bin/more is better han failing completely in this case. Bjørn
Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?
Robert Edmonds writes: > The entire DNS root zone is only 1 MB compressed and is updated about > once a day. It would be even better for privacy if the whole root zone > were distributed via HTTPS, as the initiator would not reveal to the > server any information about what TLD is being looked up. Running a local root instance is possible and easy. See https://tools.ietf.org/html/rfc7706 Bjørn
Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?
Ondřej Surý writes: > On the privacy topic... > > Slides: https://irtf.org/anrw/2019/slides-anrw19-final44.pdf > Paper: https://dl.acm.org/authorize.cfm?key=N687437 And also section 8 of https://tools.ietf.org/html/draft-reid-doh-operator-00 > And you can get to the video recording from the ANRW 2019 pages: > https://irtf.org/anrw/2019/program.html > > We can discuss (and it has been discussed) ad nauseam, but the point > is that nobody (certainly I am not) is asking for crippling DoH, but I > just strongly believe it’s in the line with other Debian work that we > should not send data to 3rd party DNS service without explicit user > consent. I agree, FWIW. User consent is required. I for one, do trust my ISPs a lot more than I trust Cloudflare or Google, simply based on the jurisdiction. > Otherwise it doesn’t make any sense to remove external links to logos >and JavaScript from the documentation and then send everything to one >single US-based provider. Exactly. I'd be worried if anything in Debian came preconfigured with DNS servers of any kind. Bjørn
Re: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)
Bernd Zeimetz writes: > On 8/11/19 12:01 PM, Adam Borowski wrote: >> restart|force-reload) >> log_daemon_msg "Restarting $DESC" >> do_stop >> sleep 1 >> do_start >> log_end_msg $? >> ;; >> >> Yes, this particular case might fail on a pathologically loaded box or with a >> very slow chip, but I don't know of a way to ask firmware if something is >> still winding down, thus what we ship is probably still sanest. > > yes, for firmware this makes sense, but I've also seen various sysv > scripts where people tried to guess the time a service needs to > shutdown, so some random sleep was added instead of handling it in a > sane way. This issues are luckily fixed forever with systemd - it just > knows, whats going on. LOL! Please try to be serious. https://www.google.com/search?q=%22stop+job+is+running%22 Bjørn
Re: Apt-secure and upgrading to bullseye
Julian Gilbey writes: > On Wed, Jul 10, 2019 at 12:31:51PM +0100, Julian Gilbey wrote: >> Hooray, buster's released! Congrats to all! >> >> So I tried upgrading my machine to bullseye today, and >> aptitude/apt-get update don't like this, giving me errors such as: >> >> E: Repository 'http://ftp.uk.debian.org/debian testing InRelease' changed >> its 'Codename' value from 'buster' to 'bullseye' >> N: This must be accepted explicitly before updates for this repository can >> be applied. See apt-secure(8) manpage for details. >> >> So I read apt-secure(8), which gives no indication of how to "accept >> this explicitly", and neither do any of the linked wiki pages. >> >> Any suggestions? >> >> (And obviously something needs changing so that people aren't stung >> when bullseye is released.) > > Ah, turns out it's a known bug with aptitude. The solution is to run > "apt update", which interactively asks what to do with these changes. If it's any comfort, I had the exact same problem. It would be nice if the warning either pointed to the apt-get(8) man page, where the solution can be found, or some hint was added to the apt-secure(8) man page. I found this section of the apt-secure(8) man page particularily unhelpful: Since version 1.5 the user must therefore explicitly confirm changes to signal that the user is sufficiently prepared e.g. for the new major release of the distribution shipped in the repository (as e.g. indicated by the codename). Those who cares which version this was added will read the changelog. Those reading the man page are more likely looking for instructions, not background info. Bjørn
Re: Debian, so ugly and unwieldy!
Adam Borowski writes: > => Install gtk3-nocsd by default in all desktop tasks but Gnome. It's not > perfect but it helps. That's nice. Thanks for the tip. I enjoy nice tools like eog and evince, but have always been annoyed by the missing window title and associated window manager context menu. Bjørn
Re: @debian.org mail
Daniel Lange writes:
> We have more people registered for DebConf ("the Debian Developers'
> conference") with @gmail.com than @debian.org addresses.
You can't fix @gmail.com. It is deliberately broken for commercial
reasons, and that won't stop with SPF and DKIM. Anti-spam is just the
current selling excuse for moving users to a closed, commercially
controlled, messaging service.
Document that @gmail.com doesn't work and ask anyone subscribed with
such an address to resubscribe using an Internet email service.
You might want to make a press announcement out of it, to prevent other
service providers from making the same mistake Google has made.
Bjørn
Re: usrmerge -- plan B?
Marco d'Itri writes: > On Nov 26, Didier 'OdyX' Raboud wrote: > >> Sorry to be blunt about this, but have you reported these? Sniping at (any) > > No, they have not. There is a lot of handwaving in this thread but very > few results of actual tests. "Migration is not (easily) reversible" was reported as important in 2016: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848626 It was immediately demoted to wishlist with this explanation: "If and when the package will be automatically installed for some reason then a warning will be appropriate. usrmerge has extra priority, is not a dependency of anything and I am not aware of anybody ever installing it by mistake." The bug was later closed when a deconf question was added. The fact that you redefined the topic of the bug does not mean that it was solved. Your whining about missing bug reports on this subject is simply arrogant. Or ignorant. Or both. Bjørn
Re: Should tasks be considered harmful?
Paul Wise writes: > On Mon, Dec 4, 2017 at 6:43 AM, Bjørn Mork wrote: > >> But how would a user without any previous knowledge of modemmanager or >> Linux networking be able to figure this out? > > It sounds like you are looking for isenkram to be integrated into the > installer so that the knowledge of which package maps to which > hardware is available to the user when doing an install and for > modemmanager to declare which devices it supports via AppStream and > for installing modemmanager to pull in networkmanager and remove wicd: > > https://tracker.debian.org/pkg/isenkram > http://people.skolelinux.org/pere/blog/tags/isenkram/ > https://wiki.debian.org/AppStream/Guidelines#Announcing_supported_hardware No, not really. I want the installation to end up with a *more* predictable set of packages. Attempting to do any sort of harware based package selection will result in less predictability. This is support hell. Imagine a Debian user trying to assist another Debian user. If you can't even establish a package set baseline, then where do you start? No, I definitely don't want some magic guessing of what packages I need. I want the default install to include a large enough set of packages supporting as many use cases as reasonable. If there are more than one alternative package providing a given service, then the default should be the one supporting most use cases. At least if there is little or no doubt. Which I believe covers the wicd vs NM case. Hardware detection during installation will also fail for common use cases like plugging in a USB modem after installation. My example had a built-in modem, but it could just as well be an external one. And even if this example was related to hardware enablement, that is only part of the problem. Replacing any core system package with something other users won't consider "default" is going to cause confusion. I guess the definition of "core system package" is something which can be discussed. But it is a fact that all the DEs come with their own set of system daemons, libraries and tools. Take it to the extreme and you end up with the kernel being the only shared package between two different DE installations. I just realized that this might appear as if I am opposing choice. That is not my intention. What I am trying to say is that I found the results of the task selection confusing, because it wasn't clear to me that I was actually choosing a different Debian derivative by selecting one of the desktop tasks. If you are going to continue to provide these variants, then it would have been better (for me at least) if every task was packaged as a separate installer image. This would also reduce the number of necessary questions during install. Bjørn
Should tasks be considered harmful?
tl;dr: Desktop tasks have unexpected (from the user point of view) side effects due to dependencies. This can be considered harmful since the installer task selection can easily can trick a user into installing a "substandard" system. Yesterday I did something I rarely do: I installed Debian from scratch on a laptop. This is not something I do a lot, simply because there is no reason with the excellent upgrade support Debian has. Even when I occasionally change hardware, I usually migrate as much configuration as possible - including the list of installed packages. I must admit that I had very high expectations based on my previous experience with Debian. I expected a smooth install ending up with a system where everything just worked. And it was close. But not quite. And the failure was so unnecessary, and potentionally so difficult to figure out for new users, that I think it is worth considering as a much larger problem than a simple installation bug. This old laptop had a built-in 3G modem (an Ericsson F3507g - not that it matters), which I "knew" would work fine in Debian. Aleksander, Dan and all the contributors have done a very nice job with ModemManager. But the modem did not work. Because ModemManager wasn't installed at all! How did that happen? I had briefly looked at desktop task choices during installation, and not being too fond of any of the DEs, I arbitrarily selected LXDE. Figured it couldn't hurt having a lightweight DE on an almost 10 year old laptop. What I missed completely was that the lxde package, which obviously is a dependency of task-lxde-desktop, has this in its recommends: wicd | network-manager-gnome So it drags in wicd instead of network-manager-gnome. Which I can perfectly understand from a lightweight point of view. But the problem is that these two packages don't support the same features, and 'lightweight' isn't a good selection criteria during installation. In a perfect world, the installer could have had sufficient information about the hardware and the users wishes to make this choice. But it has not. So it should install the options which are most likely to work for all users. Which is clearly network-manager in this case. Replacing wicd with network-manager-gnome, which drags in network-manager and modemmanger, fixed my modem issue. But how would a user without any previous knowledge of modemmanager or Linux networking be able to figure this out? As a new user, would you even dare to rip out the core network tool which was installed by default, to replace it with something else? I don't think so. Many users would be stuck with a non-working 3G modem and not being able to fix it. Which I find terribly sad, knowing the hard work put into making ModemManager work as well as it does. Now, of anyone is still reading, you are probably wondering why I didn't just open a bug instead of writing this long story here. Well, AFAICS there is no bug. There is nothing wrong with the installer. It just did what I asked it to, since I selected this specific task. I don't think it is reasonable to expect the installer to do any dependency validation or overrides. That would be crazy. T There is also nothing wrong with the task-lxde-desktop. It depends of lxde, which it obviously must do. I don't think there is anything wrong with lxde either. Recommending wicd is fine with me. It's just not suitable for everyone, and therefore unsuitable as an installation default. But that should not be a concern for lxde. And there is certainly nothing wrong with wicd. It serves its purpose, and does it well. A limited feature set is a perfectly valid design choice. So the installation end result is bad, but every package and subsystem does exactly what they are supposed to do. It is the overall system design that fails. Which is why I think this is more of a policy question than a bug. Thinking on how I went wrong, I have come to the conclusion that I would have been much better off if there were no desktop task choice at all. If I just got Gnome or whatever would be the default. Then I would also get the one and only "default set of Debian packages", without any unexpected replacements. I would of course still be free to change the default desktop selection after installation, as well as anything else. But then I would have had a much better opportunity to see the consequences, if dependencies caused important system packages to be replaced. IMHO the task selection during installation is harmful. Unpredictable (from user point of view) results cannot be avoided, since any additional package selected during installation will modify the resolved set of dependencies. I believe there was a similar problem related to automatic package selection based on detected network environment during install. This has been resolved. But the underlying issue is still there: If you allow the installer to select or deselect *any* package during installation, then it is very
Re: Help, I broke sso.debian.org for chrome - Found reason
Enrico Zini writes: > On Tue, Sep 05, 2017 at 11:37:01AM +0200, Enrico Zini wrote: > >> I refactored the certificate generation code for sso.debian.org, and the >> certificates it generates now still work in Firefox but not in Chrome. > > I found the reason: python-cryptography writes the certificate issuer > as UTF8 String while the CA certificate has it as Printable String. > Because of that, the subject names don't match bit-by-bit. > > For openssl, encoding does not matter for comparison, while for libnss3 > it does. > > I do not know if this is: > > - a bug in openssl, which should be stricter in matching > - a bug in libnss3, which should deal with encodings > - a bug in python3-cryptography, which should do a bit-for-bit copy >when copying attributes over: > > https://anonscm.debian.org/cgit/debian-sso/debian-sso.git/tree/ca/ca.py#n429 Disclaimer: I don't know the first thing about this... But reading https://tools.ietf.org/html/rfc5280#section-4.1.2.4 https://tools.ietf.org/html/rfc5280#section-7.1 and https://tools.ietf.org/html/rfc4518#section-2 which the first refers to, I believe this must be a libnss3 bug. PrintableString and UTF8String are both allowed encodings, and RFC5280 is pretty clear about name comparisons: Conforming implementations MUST use the LDAP StringPrep profile (including insignificant space handling), as specified in [RFC4518], as the basis for comparison of distinguished name attributes encoded in either PrintableString or UTF8String. Conforming implementations MUST support name comparisons using caseIgnoreMatch. Support for attribute types that use other equality matching rules is optional. Bjørn
Re: Call for volunteers: FTP Team
Abou Al Montacir writes: > On Fri, 2017-08-18 at 08:24 -0500, Matt Zagrabelny wrote: > ... >> > If someone hypothetically joins, are they allowed to rename the FTP team >> > >> > to something that doesn't include "FTP"? >> >> Archive Team. Or the A-Team for short. The only Debian team with a theme >> song. > Why Archive, maybe Queue is more accurate (Q-Team), isn't it? An invitation to join the Q Continuum might be more attractive. Bjørn
Re: Naming of network devices - how to improve it in buster
Guus Sliepen writes: > Ok, it should be clear now that the new way of naming interfaces is not > ideal, but the older ways weren't either. Let's have a look at what we > want: > > - A simple name for systems with a single Ethernet and/or Wireless > interface (the simple desktop/laptop scenario). > - A consistent naming scheme for interfaces in a system with multiple Ethernet > interfaces (the server scenario). > - Not having interface names change after reboots. I got to ask: Why? We do not have stable names for e.g. disks. Why do we need it for network devices? Yes, yes, I know you can screw up your system by configuring a dynamic device name in /etc/network/interfaces. But I believe you should be allowed to. Just like you can screw up your system by referring to a dynamic block device name in /etc/fstab. Leave the kernel network device names alone. Let them be dynamic. Just document that fact. "stable device name" is not the problem. The problem is associating configuration with the correct physical device. Note that this is not an issue at all until you add some static network configuration. Which makes it a non-issue for most end user systems, regardless of the number or type of of network devices. For static network configurations on systems with multiple interfaces, the correct and only logical place for the device association is with the rest of the network configuration. If you use NetworkManager, then it is up to NetworkManager to match it with a specific network device - if required. The rest of the system does not need to care. The remaining problem is to make ifupdown do device matching on other (and hopefully more stable) attributes than the device name. Bjørn
Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system
Samuel Thibault writes: > Vincent Bernat, on lun. 10 juil. 2017 20:55:29 +0200, wrote: > >> Other major distributions are using this new scheme (notably Ubuntu >> which has no reason to have users smarter than ours) > > The reasoning is the converse: non-techy users will just not be exposed > to interface names anyway. Debian users, however, tend to be more techy, > and do see these interface names. And basically *all* documentation > before this interface name change is now incomprehensible to techy > beginners. Not only old docs, unfortunately. The change makes it impossible to describe system independent procedures involving a network device. As an example, I happen to get a few questions regarding LTE modem configuration. Most of these users will have a single modem, so I know the kernel network interface name is 'wwan0'. Previously I could ask a user to do e.g. 'ifconfig wwan0'. Now? Depending on how "techy" the user is, I may have to write more about netdev naming policies than the real issue. This isn't something I just made up. It is a real problem for me. And I only see a fraction of the problem. I can imagine the issues for those attempting to write any docs touching Linux networking.. > I'm really worried here: this change, like a lot others done recently, > is making the Linux ecosystem yet more complex to understand, thus > raising the barrier for techy beginners yet higher. Yes. And what is most worrying is all the excuses made, often claiming the opposite. We are all going to laugh at enp0s31f6. But it looks like we are looking at a couple of years of breakage first, before the advocates move on to some other shiny project where they can solve a problem that didn't exist before they entered the scene. Bjørn
Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system
m...@linux.it (Marco d'Itri) writes: > On Jul 10, Adam Borowski wrote: > >> Predictability is important, thus let's actually have _predictable_ >> interface names. The kernel default, eth0 and wlan0, is good enough for >> most users, why not keep that? Even just ignoring the issue completely > Because you cannot know how many interfaces a system has until all of > them will have appeared. Just like you cannot know how many PCI buses a system has until all of them have appeared. But depending on the faulty assumption that PCI bus numbers are static is apparently good enough for most users? Yes, it *is* definitely a dead horse your are beating here. There is no such thing as predictable network names. Continuing to pretend otherwise will not move this discussion forward. Bjørn
Re: systemd, ntp, kernel and hwclock
Adam Borowski writes: > On Tue, Feb 28, 2017 at 10:15:23AM +0100, Daniel Pocock wrote: >> > But ntpd is also known to have a large amount of code written >> > without as much regard for security as one would hope. It seems >> > like an unnecessary risk for most systems. >> >> >> Thanks for that security tip, I'm tempted to get rid of some ntpd >> instances now > > You'd be interested in NTPsec (https://www.ntpsec.org/) then, which is a > project to review and sanitize ntpd without downsides prevalent in most > replacements (such as same-week accuracy or no managing clock drift). > > Sadly, it's not a part of stretch or even unstable yet: > https://bugs.debian.org/819806 I don't think there are enough people caring about ntp in Debian (or the world) to maintain two code bases. And the fork is still young and not "obviously better" or "clearly the one true path forward". See also https://lwn.net/Articles/713901/ for more background information. IMHO, it's very unfortunate that this fork was created, and I cannot see anything good coming out of it. It's just wasting developer resources which could have been used to improve ntp. Bjørn
Re: Bug#846002: Debian Installer Stretch RC 1 release
Andreas Tille writes: >> Since this is still an open discussion in #846002, I would have >> preferred if you would not try to force your own preference here before >> the CTTE made its decision. > > While I'm not sure whether its a personal preference or whether some > discussion I might have missed has lead to this result but I'm similar > astonished as Ole about this result without a final decision of the > CTTE. If I can offer an view from the outside of this discussion: To me it looks like a sandbox fight which started with the creative use of "Priority: important". Now it appears that the party starting the fight thinks the other party should stop throwing sand until "mommy" (aka CTTE) decides who is right and who is wrong. I have of course probably gotten all this wrong. But that doesn't really matter. The above describes how *I* subjectively perceive the situation. That is not a subject for discussion. My personal advice, since I'm out here providing opionions nobody asked for anyway, would be to start co-operating with the tasksel/installer developers instead of waiting for a CTTE decision. That's not going to solve your issues anyway. Because, as has been pointed out by several people already: This whole mess was pointless from the start. No new Debian user will ever understand the meaning of the task menu. And no experienced Debian user will use it. Adding anything there is futile. You need to get into a dialogue with the installer developers so that you can find a way to properly integrate blends. And possibly remove tasks. This is of course way too late for Stretch. Live with it. Or continue wasting everybodys time on pointless discussions and be too late for the next release as well Bjørn
Re: Can we kill net-tools, please?
Russell Stuart writes: > On Thu, 2016-12-29 at 11:38 -0800, Russ Allbery wrote: >> It certainly doesn't provide a man page that doesn't start with a BNF >> syntax description. The iproute2 documentation is awful. >> >> Also, this is not at all easy to parse: >> >> # ip -o address >> 1: loinet 127.0.0.1/8 scope host lo\ valid_lft foreverpreferred_lft >> forever > > All true. In particular the documentation produced by kernel's > networking group is a pet hobby horse of mine. It's a collaborative project open for anyone with the slightest interest in it. Sure it can need improvements. But complaining doesn't really work. Fix it instead :) FWIW, I find it much harder to document a new feature than implementing it. And I believe many others feel the same. Any help improving the docs is greatly appreciated. New networking features often have a narrow target and are added by a person knowing the specific area pretty well, but not necessarily everything else... Writing good docs in this context is difficult because your point of view is so different from the readers. > To me this thread looks like a bunch of old men grumbling that the > young'ins have taken over what they created and turned the tools they > were comfortable with into something unrecognisable. It's true - they > did do that, and it's true it was unnecessary. Note that the reason there are two sets of tools is exactly because they *didn't* turn the existing tools into something unrecognisable. The existing tools were left alone when the kernel API went from ioctls to netlink. But I see no point in the subject of this discussion. Leave net-tools as they are for anyone used to them. "Priority: important" seems wrong, though. Bjørn
Re: Can we kill net-tools, please?
Russ Allbery writes: > Christian Seiler writes: >> On 12/29/2016 08:38 PM, Russ Allbery wrote: > >>> ip address also has one of the worst output UI decisions I've ever seen, >>> namely this line: >>> >>> inet 192.168.0.195/24 brd 192.168.0.255 scope global dynamic wlan0 >>> >>> specifically "192.168.0.195/24", which is notation (IIRC) invented by this >>> command, > >> Nope, that's RFC 4632, Section 3.1, where that was introduced >> first, see >> https://tools.ietf.org/html/rfc4632#section-3.1 > > No, I'm not talking about CIDR notation, which of course is long-standing > and familiar. I'm talking about randomly appending a CIDR suffix to > something that is obviously *not* the base for that CIDR block. > > In other words, 192.168.0.0/24 is fine. The problem is with deciding to > merge two completely different things (a CIDR network specification, and > an individual IP address) in this weird hybrid notation that, by RFC 4632, > would mean the network starting at 192.168.0.195 and extending for a /24. > Which is a nonsensical specification. I believe that is a mis-interpretation of that RFC. The examples are all network addresses, but I don't think there is anything there that restricts the CIDR notation only to that class of IPv4 addresses. FWIW, the notation is much older and has been used for IPv4 address + mask long before that RFC or the introduction of the "ip" tool. I am unable to find the original first use, but here's at least one older reference (from 1998): https://tools.ietf.org/html/rfc2373#section-2.3 "The text representation of IPv6 address prefixes is similar to the way IPv4 addresses prefixes are written in CIDR notation. An IPv6 address prefix is represented by the notation: ipv6-address/prefix-length " The IPv4 CIDR notation was obviously already well enough known to be used to explain the new IPv6 notation. I believe the above paragraph would be very confusing, to the point of not making sense at all, if the IPv4 notation was known to be used only for network address + prefix-length. > IIRC, this was done in ip to "save space" instead of using the natural > expression, namely: > > 192.168.0.195 net 192.168.0.0/24 "save space" by removing redundant information was pretty much the only reason to introduce the prefix-length, wasn't it? Well, maybe not... It also prevents anyone from trying to configure a netmask with holes in it. But if you always had to include the redundant network address, then you wouldn't save any space. What would the point of the CIDR notation be then? You might as well use one of the mask notations: 192.168.0.195 0.0.0.255 192.168.0.195 255.255.255.0 They are just as short (and commonly used, just like 192.168.0.195/24 is) > Saving space in UI output intended for humans by introducing new notation > is almost never a good idea. True. But in this case it makes the result easier to read by removing duplicate information. That is good. Bjørn
Re: Bug#830624: ITP: xplayer -- Simple media player based on GStreamer.
Emilio Pozuelo Monfort writes: > On 09/07/16 22:31, Franciscarlos Santos Soares wrote: >> Hi Emilio! >> >> Thank you for contacting us. In fact, like independent application of any >> DE, >> but they were compatible with the traditional look of windows and based on >> the >> GTK library. So would provide a good working environment in the old >> computers >> that read daily in public schools that work. > > I found http://segfault.linuxmint.com/2016/02/the-first-two-x-apps-are-ready/, > which makes things clearer. This seems to be a cross-desktop (Mate, > Cinnamon... > XFCE?) project to provide some core apps. Which we wouldn't end up with > multiple > forks of the same stuff, and that addresses my concerns. That's the forking version of https://xkcd.com/927/ , isn't it? Bjørn
Re: Putting default config files in /usr [was; (newbie) Disruptive LIRC package update.]
Bjørn Mork writes: > "/usr/lib/sysctl.d/" is systemd specific. Dropping files there won't do > anything unless you run the systemd-sysctl service. Sorry, should have researched this better first. sysctl WILL use "/usr/lib/sysctl.d/" if it exists. procps won't create it, but it is supported. I'll keep quiet for a while now... Bjørn
Re: Putting default config files in /usr [was; (newbie) Disruptive LIRC package update.]
Tom H writes: > systemd isn't the first package to allow/promote shipping distro > settings in "/lib" or "/usr/lib" and overriding them via "/etc"; udev > and polkit/policykit have behaved like this for a long time. There's > also "/usr/lib/sysctl.d/" where a distro ship settings that can be > overridden via "/etc/sysctl.d/". "/usr/lib/sysctl.d/" is systemd specific. Dropping files there won't do anything unless you run the systemd-sysctl service. "/etc/sysctl.d/" used to be owned by procps, and will still be used by /etc/init.d/procps whether or not you run systemd-sysctl. I don't think anyone wants another systemd thread, so I suggest you all keep the systemd examples to a minimum. It's a bloody mess. Bjørn
Re: Bug#777643: general: possibly, some keyboard layouts should use U+22C5 DOT OPERATOR instead of U+00B7 MIDDLE DOT
Nikolaus Rath writes: >> How dare you write ... instead of the proper … :-P > > I'm curious, how do you type that in conviently? I hope it's not copying > and pasting from a template file, and remembering (and/or finding out) > the X11 Compose sequence seems cumbersome too. I see that you have got a number of methods, but just wanted to note that … is simply "AltGr + ." on my default Norwegian keyboard layout. That's only a "Shift" away from the middle dot BTW, to keep this on topic :-) Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87fvaa880h@nemi.mork.no
Re: DE features dependent on Systemd
Josselin Mouette writes: > Bjørn Mork wrote: > > We support non-systemd-as-pid-1 configurations, but they still run > > logind through systemd-shim. > > systemd-shim is not essential. You can still install jessie without > systemd, and hence without running logind. > > This is completely off-topic. Yes, but you should expect being corrected when your off-topic posts are wrong. > We are talking about the anti-feature of adding UID=1000 to the audio > group in the installer. Are we? I was talking about making audio work for the first-user. I see that as a feature. So we disagree. That's fine. Can we discuss facts instead of opinions? > This is only relevant for desktop installations, That's narrow minded. Audio does work and is relevant for non-desktop installations. Making audio support depend on some DE is definitely a regression. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87h9xcolih@nemi.mork.no
Re: DE features dependent on Systemd
Josselin Mouette writes: > We don’t support non-logind configurations. You might not. AFAICS, Debian does. > We support non-systemd-as-pid-1 configurations, but they still run > logind through systemd-shim. systemd-shim is not essential. You can still install jessie without systemd, and hence without running logind. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87lhmooqkj@nemi.mork.no
Re: Using USB serial device with a cdc-acm driver
Dmitriy Fitisov writes: > we have a small device of our own, which communicates through serial USB on > Windows. > Now we need it to work on Raspberry (yes, I know this is Debian, which is > Raspberry based on). > USB descriptors configured as a modem, so, when I connect it to Linux, > cdc-acm module is loaded. > However, there is apparently some process which is watching modems, so on > connection > I got some info on my device - on Ubuntu it is AT commands, for which I have > adapted firmware > (seems ModemManager is running), but on Raspberry I cannot find out what > process attaches > to my "modem" and what it wants. lsof /dev/ttyACM0 Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/874mtesbmk@nemi.mork.no
Re: enforced systemd services
Marc Haber writes: > Indeed. Do we really have to pull that from a video or presentation > slides? Is this part of the official systemd docs anywhere? I don't know of any collection of all security related directives, but you can find an index of all unit file directives in systemd.directives(7) with pointers to the man pages where they are described further. If anyone ever doubted that systemd is bloated with far too many features, then I do recommend reading systemd.directives(7) ;-) You'll find the Private* and Protect* directives described in systemd.exec(5) for a start. Container services are of course nice features to have, and it is so elegant to just configure them with a few keywords in a configuration file. But this mix-it-all-together design does not come for free... Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/878uiz8rgg@nemi.mork.no
Re: Being part of a community and behaving
m...@linux.it (Marco d'Itri) writes: > On Nov 17, Steve Langasek wrote: > >> > This is what many still (retorically) wonder about: we the systemd >> > maintainers did not reject that change, >> https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=15;bug=746578 > Please try to be less selective in your quoting: the issue was still > being discussed. I see. So any systemd bug with a 'wontfix' tag is still considered open for discussion? That's good to know. Thanks. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87bno6f8h2@nemi.mork.no
Re: Being part of a community and behaving
Brian May writes: > On 14 November 2014 04:20, Carlos Alberto Lopez Perez > wrote: > >> The last one that I read is that udev is going to stop working on >> non-systemd systems: >> >> http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html >> >> > I don't read anything in that post that says this. > > Am guessing you a referring to the "Also note that at that point we intend > to move udev onto kdbus as transport, and get rid of the > userspace-to-userspace netlink-based tranport udev used so far" quote. > > Which would suggest that udev might stop supporting the > userspace-to-userspace netlink-based transport in the future. However, > unless I am mistaken, I don't think this means it will no longer work on > non-systemd systems. The next sentence after the one you quote is: "Unless the systemd-haters prepare another kdbus userspace until then this will effectively also mean that we will not support non-systemd systems with udev anymore starting at that point." Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87bnoagd0c@nemi.mork.no
Re: systemd - some more considerations
Tollef Fog Heen writes: > ]] Norbert Preining > >> > systemd needs cgroups, that's pretty well established. Arguably, it >> > should die with a clearer message. >> >> No, NO NOO >> >> *IT*SHOULD*NOT*DIE*!!! It is in PID 1. Please digest that. > > Am I understanding you correctly that you don't think there are any > situations where compiling out features from the kernel can lead to pid1 > not working would be acceptable? The main problem is how you resolve the "not working". Dying will never a sane way to give up from pid 1. Try exec'ing something else instead, like a shell or a stripped down init not needing all those optional kernel fatures. And wrt the question about required kernel feaures: Why should the systemd pid1 require more features than other init systems? I have been told before when complaining about putting additional complexity into pid1 that this isn't true - that systemd really doesn't add dependencies to pid1 compared to alternative init systems. This doesn't seem to be completely true. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/877g768yhm@nemi.mork.no
Re: pulseaudio related problems....
John Paul Adrian Glaubitz writes: > On 02/17/2014 01:37 PM, Norbert Preining wrote: >> Why can you not simply say something like: "Well yes, there seem >> to be some problems and we will try to fix them if we can get hold >> of enough input. You DDs should be able to provide decent information >> to help track the problems down." > > Then why on earth aren't those people who are affected providing some > more information? > > This is exactly what I was talking about: If your solution is > unstalling an affected package, then you're obviously not > interested in fixing it in the first place. > > If you want me to help you with your problem, you need to provide > something I can work on. Just claiming it doesn't work isn't helping > in this situation, I don't have a crystal ball I can consult in this > case. The goal of most users will be "have sound", not "install pulseaudio". This defines both the problem and the solution, from the users perspective. A package which appear to be non-functional at install time is not likely to receive any bug reports at all. Feel free to whine about that. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k3ctc08e@nemi.mork.no
Re: systemd - getting started?
"Iain R. Learmonth" writes: > Things I'd like to see are: > > * A systemd primer (like what is a service file?) > * Packaging documentation for systemd (some has been started [1]) > * How to hack together a service (this is something I did quite a lot > for homebrew scripts on servers) > > There are probably other things that others would like to see too. > > I can see a lot of enthusiastic systemd supporters on the list, I'm not quite sure I qualify as one :) But I'd still like to recommend Neil Brown's excellent article series on LWN: http://lwn.net/Articles/584175/ http://lwn.net/Articles/584176/ You'll have to subscribe to read those now (or wait). But I assume the Debian developers group subscription still applies? Ref http://lwn.net/Articles/13797/ I'm not a DD, so I cannot verify that... Anyway, LWN is certainly worth paying for, even if you're not going to use systemd :-) Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87txc448it@nemi.mork.no
Re: removal of the vacation package
Ansgar Burchardt writes: > Bjørn Mork writes: > >> Care to provide a pointer to an example? > > RFC 5230, sections 4.2, 4.5, 4.6 and 8. Thanks for the pointer. Are there any implementations of RFC 5230 in Debian? Both "apt-cache search 5230" and "apt-cache search sieve vacation" only return libnet-sieve-script-perl, which is more of a toolbox than an actual sieve enabled MDA. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k3e15r1w@nemi.mork.no
Re: removal of the vacation package
Ansgar Burchardt writes: > Bjørn Mork writes: >> Is there such a beast with feature parity? vacation has a few nice >> defaults, like ignoring list mails and only sending one message per week >> to each receiver. Having every end user implement similar behaviour in >> sieve isn't likely to happen. >> >> The world has become a lot more stupid since vacation was written > > The statement in the second paragraph is false. OK, then I got the wrong impression from the number of "out of office" messages I see on public mailing lists. > This also answers the first paragraph. Care to provide a pointer to an example? Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ioto9s1p@nemi.mork.no
Re: removal of the vacation package
m...@linux.it (Marco d'Itri) writes: > On Jan 12, Stefano Zacchiroli wrote: > >> It still seems to have a fair number of loyal users though. I see your > popcon says 1867 have it installed, but only 222 "voted". > >> If we do have such a >> replacement (I just don't know) please mention it in the removal bug >> report. > I agree with waldi that the most simple replacement is a Sieve-enabled > LDA. Is there such a beast with feature parity? vacation has a few nice defaults, like ignoring list mails and only sending one message per week to each receiver. Having every end user implement similar behaviour in sieve isn't likely to happen. The world has become a lot more stupid since vacation was written > On Jan 12, Ian Jackson wrote: > >> I might want to adopt it. What's wrong with it not supporting >> MIME ? AFAIAA it doesn't need to do much parsing of the incoming >> messages. > As the last bug shows, it is supposed to parse the Subject header. This doesn't look like a MIME bug to me. It looks like vacation truncates multiline subjects. There is absolutely no reason it should try to parse any MIME. And the truncation doesn't really matter for most use cases (returning a static message). IMHO this could just be documented and tagged as wontfix if you wanted to. >> The set of bugs looks tractable to me. Do you have a half-prepared >> upload somewhere or is the versionn in the archive the most recent ? > No, I have really ignored it since december 2003. > If you want it, it's yours. Good to see that there are developers interested in keeping it alive. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vbxoao4p@nemi.mork.no
Re: overriding udev rules
Uoti Urpala writes:
> Russ Allbery wrote:
>>Kay Sievers writes:
>> > Hmm, why would upgrades break?
>>
>> > The old file would still be there, rename the devices (if you keep the
>> > patch to swap names, which upstream does not support any more), and take
>> > precedence over tht new names; the old rules file would just not be
>> > updated anymore when new devices appear.
>>
>> Manually-deployed /etc/network/interfaces files that assume a specific
>> device naming come to mind. We have tons of those at work.
>
> Why would those break? Just having a manually-deployed
> /etc/network/interfaces file that uses names like "eth0" should not
> break upgrades, because as mentioned in the part you quoted, the
> existing already-generated rules should still trigger and keep renaming
> the same card to eth0. So you need to assume something more to have an
> example of a problem case.
Things will break because the new scheme changes interface names which
never have been added to the generated rules.
As just one example, these names have been in use at some point in time
on my laptop:
bjorn@nemi:~$ egrep ^iface /etc/network/interfaces
iface lo inet loopback
iface eth0 inet manual
iface wlan0 inet manual
iface default inet dhcp
iface mbm0 inet dhcp
iface mb0 inet dhcp
iface wwan0 inet dhcp
iface wwan1 inet dhcp
iface test inet dhcp
iface debug inet dhcp
iface mob inet dhcp
iface mbb inet dhcp
iface testv4 inet dhcp
iface testv6 inet6 manual
iface usb0 inet dhcp
iface usb1 inet dhcp
iface tap0 inet manual
iface tap0.42 inet manual
iface bnep0 inet dhcp
Only two of them have persistent entries and can be expected to continue
working:
bjorn@nemi:~$ grep NAME /etc/udev/rules.d/70-persistent-net.rules
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:21:86:a3:25:7d", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="0c:8b:fd:08:09:71", ATTR{dev_id}=="0x0", ATTR{type}=="1",
KERNEL=="wlan*", NAME="wlan0"
I'm not claiming that I use all those entries, and some of them were
added due to breakage caused by the existing scheme. But this doesn't
change the fact that converting to the new scheme will cause additional
breakage, e.g. by renaming my internal wwanX devices to wwsomething.
I'll leave up to others to decide whether such breakage is acceptable or
not.
Bjørn
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ob81t0u0@nemi.mork.no
Re: overriding udev rules
Michael Biebl writes: > The persistent network interface naming rules are already skipped if > udev is run within a virtual machine. Which made me look closer at /lib/udev/rules.d/75-persistent-net-generator.rules I find it a bit strange that it has lots of logic involving different OUIs, but doesn't seem to care at all about the "addr_assign_type" sysfs attribute. I believe you never should generate any persistent rules if this attribute is different from 0 (NET_ADDR_PERM). And I'll now go fix some drivers which doesn't set it as appropriate. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ioyy3r6q@nemi.mork.no
Re: Survey answers part 1: systemd has too many dependencies, …
Michael Stapelberg writes: > since some people might not read planet debian, here is a link to my > first blog post in a series of posts dealing with the results of the > Debian systemd survey: > > http://people.debian.org/~stapelberg/2013/06/09/systemd-bloat.html I was hoping you would cover my reason why I fear the "too many dependencies": external dependencies obfuscates what code is part of pid 1 and what is not. Some (most?) of the external projects you depend on are probably not developed with this use case in mind, and hence are not suitable for being used like this. This is not a critisism of the externel libraries. There is quite a difference between writing code which can exit and writing code which cannot. No sane person will attempt to do the latter unless strictly required. You claim that the systemd code using these dependencies is simple, and I have no reason do doubt that. But you ignore the fact that you make the external code part of systemd. That code also needs to be audited as if it were an integral part of systemd. You could just write a "libpid1" and a 5 line application using that library. It should be obvious that auditing the 5 line application would be unsufficient. The point is that it is not obvious that all these external dependencies are suited for use by systemd, and that the responsibility for ensuring that they are lies with the systemd project. Not with the external projects. I understand that there are lots of developers having a hard time understanding that there is a difference between - desktop application depending on libfoo, and - criticial (securitywise, stabilitywise, other) application depending on libfoo You do of course not have to agree. This is my personal opinion only. But I believe it is useful to read Jamie Zawinski's view on screensavers and toolkit library dependencies, and try to figure out how that can be relevant to systemd and external dependencies: http://www.jwz.org/xscreensaver/toolkits.html Using a library in a critical application will make any harmless library bug into a critical bug. Are the maintainters of those dependencies really ready to handle that? This is the primary reason why the list of dependencies terrifies me. Not any of the four reasons you list, which, although valid, are only minor issues which could be outweighed by advantages offered by the dependency. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zjuzwrb9@nemi.mork.no
Re: default MTA
Jean-Christophe Dubacq writes: > And in my experience, email tends to be much more fragile than dbus. The warm fuzzy feeling you get when you don't know there is a problem... > How many times have I suddenly looked > at the queue of a computer that has been mis-configured and that > accumulated thousands of email from its system trying to repeatedly warn > the user that, well, the email smarthost cannot be contacted? Yes, and dbus would have just dropped the messages that couldn't be delivered instead of queueing them. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8761xzlg2n@nemi.mork.no
Re: default MTA
Marc Haber writes: > On Thu, 30 May 2013 06:46:46 -0400, Scott Kitterman > wrote: >>Even if they are using a system >>that allows them to go back and review their notification history when they >>return to their system, > > It just occurred to me that you are describing a mail client. Let's add biff and we have cross-desktop real-time notification in place :) Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8738t4oe7z@nemi.mork.no
Re: default MTA
Ben Hutchings writes: > On Wed, May 29, 2013 at 09:06:59PM +0200, Adam Borowski wrote: >> On Wed, May 29, 2013 at 05:11:35PM +0200, Josselin Mouette wrote: >> > Le mercredi 29 mai 2013 à 16:31 +0200, Javier Fernandez-Sanguino a >> > écrit : >> > > Take for example, smartmoontools [1]. Currently, if an end-user >> > > installs smartmoontools and a hard-disk fails (i.e. smartd detects a >> > > problem with one HD) he will *not* see any notification: the failure >> > > is sent through local e-mail. >> > >> > He will see a notification on his desktop. Clear, understandable and >> > translated in his configured language: >> > https://git.gnome.org/browse/gnome-disk-utility/tree/src/notify/gdusdmonitor.c >> > (The code is different but already here in squeeze and wheezy.) >> >> What you propose requires: >> * adding desktop environment specific code to every facility that may need >> to send notifications >> * adding such notifications to every other desktop environment > > Wrong, we already have org.freedesktop.Notifications in GNOME, > KDE and Xfce. > > So those two points become: > > * adding cross-desktop code to every facility that may need to send > notifications > * adding a notification daemon to task-lxde > > There are libraries to help with the first point, of course. Wouldn't a daemon watching /var/mail/root and turning any mail into desktop notifications solve most of this, while still allowing the same notifications to reach a sysadmin on non-desktop systems? The issue that worries me most about these desktop notification plans is the possibility that some package may decide to unnecessarily drop support for non-desktop systems, adding dependencies on the desktop notification system. I believe we already have had a few examples of such unnecessary dependencies on services which are "nice to have", like GNOME depending on NetworkManager for example. The "Clear, understandable and translated in his configured language" point is unrelated the notification system. That requirement should be at least as strict for any mail to root. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871u8opye0@nemi.mork.no
Re: default MTA
Russ Allbery writes: > Bjørn Mork writes: > >> The local MTA serves as a common configuration for the external SMTP >> server, with a well known interface supported by every single package >> which wants to send mail. > > And which requires storing passwords or other authentication credentials > on disk if your external SMTP server requires authentication (increasingly > common), which is bad security practice (not to mention awkward for a lot > of people to configure). Whereas using an external MTA directly in the > mail client means the mail client has the ability to prompt you > interactively for authentication credentials or use the system keyring to > store them, which is somewhat more secure. Yes, this is a problem common to any system wide authenticated service, like for example a bluetooth keyboard or a PPP network connection. I still don't think it makes any sense delegating the configuration to packages needing those services. The keyboard and the network connection are system services, even if they need credentials stored in the file system. IMHO, the same goes for SMTP. There may not be as many packages needing it as those needing a keyboard. But I'm guessing that there still are a handful SMTP clients installed on an average single user desktop system. And it does not make sense to have each and every one of those packages configure external SMTP access independently. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vc637y6s@nemi.mork.no
Re: default MTA
Josselin Mouette writes: > Le mardi 28 mai 2013 à 13:07 +0200, Bjørn Mork a écrit : >> The local MTA serves as a common configuration for the external SMTP >> server, with a well known interface supported by every single package >> which wants to send mail. > > Which packages are entitled to send mail to the outside without > configuration from the sysadmin, exactly? All packages are installed and configured by the sysadmin. So that would be none. But there should be exactly one package asking the sysadmin about smtp smarthost settings. The other mail sending packages should just depend on that package and reuse the settings already configured. > We are talking about a default configuration, and the only useful thing > in a default configuration is local mail. I disagree. The only useful default configuration is a default-mta package asking how to deliver both local and remote mail, and holding the sysadmin's hand while setting up delivery to a smarthost. Possibly mapping local accounts to a single remote address. > Local mail not being read by anyone on most machines. This we can agree on :) >> I don't see the point discussing this at all until there is an >> alternative interface with a similar level of support. Otherwise you >> are just going to repeat the MIME support mess again. > > Just like for the MIME support mess, the damage is already done. Nobody, > I repeat, nobody, ever reads local mail on most desktop systems, and > even many server systems. For desktops, we need to rely on direct user > notification. For servers, careful people rely on real-time monitoring. > > Local mail is a quick solution for persistent notification of the system > administrator, but it doesn’t scale at all when you have more than 3 > machines under your control. > > I don’t think the situation is that bad. We could probably work on > alternative notification systems for cron jobs, but for the other > important use cases of local mail, we already have what we need. Sure. Yes, I agree that local mail isn't necessarily the answer to any notification requirement. But I don't think that means that it never is the answer. There are situations where local mail notification is fine. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8738t79h4i@nemi.mork.no
Re: default MTA
Josselin Mouette writes: > Le mardi 28 mai 2013 à 10:34 +0100, Jonathan Dowland a écrit : >> There is an impedence mismatch between packages which consider an MTA and the >> sendmail interface to be standard and those desktop components that make no >> such assumption. If we are going to keep ensuring a local MTA/sendmail >> interface >> going forward, I'd love to see it better integrated into the desktop stack. >> (In >> fact I still battle debconf-stuff-on-top-of-exim from time to time, when I >> have >> a system where I don't want any local mail.) > > I don’t think desktop components lack integration with the MTA. For > example, evolution will use /usr/sbin/sendmail by default. The problem > is that usually, the MTA will not be configured to do anything useful, Moving the configuration from 1 package providing the MTA to N packages is certainly not going to improve this... > so users are better off using an external SMTP server, usually with > authentication. In what why does a local MTA prevent that? The local MTA serves as a common configuration for the external SMTP server, with a well known interface supported by every single package which wants to send mail. I don't see the point discussing this at all until there is an alternative interface with a similar level of support. Otherwise you are just going to repeat the MIME support mess again. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k3mj9xbo@nemi.mork.no
Re: Contributor agreements and copyright assignment
Russ Allbery writes: > Bjørn Mork writes: > >> IANAL, but I believe you are wrong there. You give them much wider >> rights than this by assigning the copyright to the FSF. The copyright >> owner is free to relicense the work in any way they want. > > Have you see the copyright assignment contract that you make with the FSF? Seen and signed :-) > It would be a breach of that contract for them to relicense the work in > any way they want. The contract really does try to address this issue. > > The assignment isn't a unilateral act. The FSF promises to do things in > return for the assignment. Yes. It is pretty clear that the FSF as such cannot redistribute your work under another license. I most certainly may be wrong, and likely is, but I still believe there still is a tiny possiblity that the copyright assignment is transferred as an asset, without being bound by the other parts of the contract. > Now, bankruptcy is indeed a potential problem, since bankruptcy courts can > do all sorts of things, including dissolve or partly dissolve contracts. > But even in that admittedly dangerous situation, I do think there's a fair > amount of legal protection involved. (And one gets some additional legal > protection from the FSF being a non-profit under US law.) Good. Let's hope it won't be necessary. >> I still don't think issues like this should prevent anyone from >> contributing to any currently open source project. Yes, it will be >> frustrating if your work ends up being part of some proprietary >> software, but it's even worse if you cannot contribute to these projects >> out of fear of that happening. > > The main issue for some of us is not so much the ethical objections to > these sorts of agreements but rather the fact that our employers flatly > are not interested in signing anything of the sort, ever, with anyone. > Much of my free software work is done as part of my day job, and my > employer is unwilling to sign any of these agreements (but is fine with me > releasing my work under free software licenses). Yes, that is an important problem with such policies. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87boe87vqv@nemi.mork.no
Re: Contributor agreements and copyright assignment (was Re: Really, about udev, not init sytsems)
Ian Jackson writes:
> Barry Warsaw writes ("Re: Contributor agreements and copyright assignment
> (was Re: Really, about udev, not init sytsems)"):
>> FTR: http://www.canonical.com/contributors
>
> That allows Canonical to make proprietary forks of the code (eg, to
> engage in the dual licensing business model). This is very
> troublesome for me; it's too asymmetric a relationship.
>
> This is a right that the FSF assignment doesn't give the FSF
IANAL, but I believe you are wrong there. You give them much wider
rights than this by assigning the copyright to the FSF. The copyright
owner is free to relicense the work in any way they want.
The rights transferred in the Canonical agreement are very limited
compared to this.
> and which the FSF wouldn't exercise even if they had it.
No, the current FSF wouldn't do that. But how about the company taking
over assets after the FSF lose a major lawsuit? That company will then
own the copyright on your work, including the rights to relicense it.
I still don't think issues like this should prevent anyone from
contributing to any currently open source project. Yes, it will be
frustrating if your work ends up being part of some proprietary
software, but it's even worse if you cannot contribute to these projects
out of fear of that happening.
BTW, never take any legal advice from me.
Bjørn
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k3sxlggu@nemi.mork.no
Re: Really, about udev, not init systems
Tollef Fog Heen writes: > ]] Bjørn Mork > >> "The default 'configure' install locations have changed. Packages for >>systems with the historic / vs. /usr split need to be adapted, >>otherwise udev will be installed in /usr and not work >>properly. Example configuration options to install things the >>traditional way are in INSTALL." >> >> Just stating the facts. I see no reason to discuss these issues any >> further. > > «default location» vs «architecture of udev». Reality check, please? OK. Reality check came back with: Nothing of this really matter to me at all. I am sure a working udev branch will continue to exist, one way or the other. I started feeling a bit nervous back when Mauro desperately tried to make the linux media drivers conform with the new udev firmware loading restrictions. But I managed to stay calm, and it all turned out quite well. One of the nice effects of open source is that there are absolute limits to crazyness. People are free to do whatever crazy stuff they want. Someone else will step forward and fork it back to sanity if necessary. This system works very well. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87a9u11u7f@nemi.mork.no
Re: Really, about udev, not init systems
Cyril Brulebois writes: > Thomas Goirand (28/11/2012): >> That's not truth anymore, since AFAIK rules of udev moved to /usr. > > May I suggest some fact checking? Try “dpkg -L udev” for a start. Yes, the Debian package is OK and I assume it will continue to be. But I believe Thomas was referring to the recently (udev 176) changed upstream default. See e.g. http://www.freedesktop.org/software/systemd/man/udev.html : "udev configuration files are placed in /etc/udev and /usr/lib/udev." Upstream has explained it this way in the changelog: "The default 'configure' install locations have changed. Packages for systems with the historic / vs. /usr split need to be adapted, otherwise udev will be installed in /usr and not work properly. Example configuration options to install things the traditional way are in INSTALL." Just stating the facts. I see no reason to discuss these issues any further. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871ufd3nfx@nemi.mork.no
Reply-To munging (was: Re: "Do not CC me")
Thomas Goirand writes: > The solution to this is very simple. Have the > mailing list manager to add a Reply-To: header > on each messages. > > I've done this on few of the lists I manage, and since > then, nobody sends double-messages. > > But, probably, mailman is too stupid to have such > kind of options (I use (and maintain in Debian) MLMMJ, > which is used by big distros like Gentoo and SUSE). > > Thomas > > P.S: I know that the list manager adding a Reply-To: > header breaks the RFC, and people setting-it up > explicitly on their mail client, but it works very well... Fascinating. Did I miss the announcement of "Repeat-Every-Controversial-Discussion month" or what? Anyway, to save us some time, could everybody please just read http://www.unicom.com/pw/reply-to-harmful.html http://www.metasystema.net/essays/reply-to.html http://woozle.org/~neale/papers/reply-to-still-harmful.html and agree that we are not going to agree on this subject either? There is absolutely no reason to repeat any of the arguments found in those three documents here. Anyone reading this list should be capable of googling. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wqx8qx47.fsf...@nemi.mork.no
Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning
Serge writes: > 2012/8/30 Wouter Verhelst wrote: > >>> How do you suppose it's possible to undo arbitrary network >>> configuration done by arbitrary set of tools when there's no central >>> place to hold such information (and can't possibly be)? >> >> Actually, the kernel holds that information. Any tool can just query the >> kernel for information, and decide what to do with what's returned. > > Not sure. Will it work for user-space configuration too? I.e. `ifdown` > may have have to stop `dhclient` and `wpa_supplicanf`. Is it possible > to detect such cases automatically? If you start dhclient or wpa_supplicant on ifup, then you naturally need to query and deconfigure those tools on ifdown too. There is a perfect symmetry here: "up" use rtnetlink => "down" queries/deconfigures rtnetlink "up" use wpa_supplicant => "down" queries/deconfigures wpa_supplicant "up" use dhclient => "down" queries/deconfigures dhclient "up" use pppd => "down" queries/deconfigures pppd etc. Layered combinations of the above is of course common and must be supported. But I fail to see the point of this discussion. Post patches for NM and/or ifupdown implementing the features you'd like to see. No need for all the theoretical mumbo-jumbo, implying that someone else should do the job. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878vcu3yhi@nemi.mork.no
Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning
Stephan Seitz writes: > On Mon, Aug 20, 2012 at 01:08:53PM +0200, Bjørn Mork wrote: >>Never mind wireless lan where you've got a well defined kernel API. Try >>to configure a modern 3G/LTE modem using ifupdown, and you will see the > > Is this something different from an UMTS usbstick? No. > I plug it in, get a > /dev/ttypUSB0 and do a „pon umts”. No need for NM and Co. Sure. But you didn't actually configure the device here, did you? And you didn't notice that the device fell back from LTE to UTMS. Or that it suddenly started roaming to the network on the other side of the border. Etc. You didn't even notice that the connection failed because the PIN code was wrong. Or did you? OK, then your chat script has started looking like a small ModemManager application... Oh, yeah, and of course /dev/ttyUSB0 wasn't the AT port. It was the QCDM port so the chat script just timed out. The connections provided by these devices are dynamic by nature, and they typically have management protocols supporting notifications from device to host. You may of course ignore this and state that the device "works" in a static configuration, but most users will want some monitoring daemon allowing them to make intelligent decisions based on current available devices and networks. A little like what wpa_supplicant does for wireless LANs. That's what ModemManager provides. But yes, if „pon umts” is enough for you then you don't need NM (or even ifupdown - pppd and vim will do). By modern 3G/LTE modem I mean a device supporting CDC MBIM or a vendor specific management protocol like QMI. The firmware of most of these devices will export a basic AT command set and support PPP on one or more serial ports, but that only supports a very limited usage pattern IMHO. And when it comes to LTE, also limited speed. Some vendors implement AT commands for initiating "NDIS" connections, but these are exceptions and are likely to go away over time as more and more devices get a "intented for Windows 8" label or somthing like that. And it didn't work with your "pon" in any case. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pq6liwmw@nemi.mork.no
Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning
Christoph Anton Mitterer writes: > On Sun, 2012-08-19 at 19:41 +0200, Marco d'Itri wrote: >> NM, as a design goal, is not supposed to be able to manage every >> possible configuration. > Well but then it shouldn't be kind of a default package. No it shouldn't. And it isn't either. gnome-core is not default. > And yes, I > know, strictly speaking it's neither required nor essential. > But as I mentioned before, more and more uses it... and one usually > get's it already with gnome-core. Except for GNOME, what other unrelated packages depends on NM? The GNOME dependencies are deliberately broken to bring in as much cruft as possible, but GNOME is neither required nor default so what's the problem? Why do you install gnome-core if you don't want the resulting package mess? > And to be honest, I don't think that it's impossible that NM would > integrate well with ifupdown (and the others). I believe it already does. Any problems with this integration should be reported as bugs. Neither NM nor ifupdown is currently capable of dealing with every possible networking setup (NM fails on complex static configurations, ifupdown fails on dynamic stateful configurations). And I expect this is how it will be for the foreseeable future. At least that's how I understand the current scopes of those packages. Debian need *both*, and any efforts in this area should be put into making them interoperate. Never mind wireless lan where you've got a well defined kernel API. Try to configure a modern 3G/LTE modem using ifupdown, and you will see the usefulness of a framework like NM and it's companion ModemManager. Yes, there are of course bugs and missing features. But let's fix them then. NM upstream is very active and easy to co-operate with. And before someone asks: There won't be any "standard wireless extensions" for wan connections. That sort of thing is just not considered appropriate for the kernel anymore. Drivers export the device native control channel(s), and leave the rest of the job for userspace libraries. This means that you will need something like ModemManager, oFono or similar to provide a common device independent application interface. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871uj1kegq@nemi.mork.no
Re: Recommends for metapackages
Jean-Christophe Dubacq writes: > On 11/07/2012 11:12, Andrei POPESCU wrote: >> On Mi, 11 iul 12, 10:55:16, Jonas Smedegaard wrote: >>> >>> The feature of _allowing a subset of packages to be removed that was >>> _ensured_ to be installed: Impossible without defeating the feature of >>> _ensuring_ those same package are installed. >> >> Agreed. However, unless I missed something I haven't seen any arguments >> for why gnome-core really needs to _ensure_ that network-manager-gnome >> is installed, other than "upgrade issues" without any other details. > > If my memory does not fail me, support from upstream (since > network-manager is a core component of Gnome). I may be wrong. That must be an upstream *Gnome* bug then. But it is most certainly a bug. Network Manager is not intended as an one-size-fits-all application. I have never been a great fan of Network Manager, but for various reasons I've taken some time to actually get to know it lately. And that has been enlightening. Turns out that it works really well for the use cases it supports, and it isn't *meant* to be used for every possible use case. Contrary to what you would be led to believe by the strict Gnome dependency. I do recommend everybody, especially the Debian Gnome maintainers, to read what Dan Williams said here yesterday: https://mail.gnome.org/archives/networkmanager-list/2012-July/msg00168.html Instead, I believe our goal is to make NM useful enough, easy enough, and understandable enough, that people *want* to use NM rather than wading through a bunch of scripts. We don't want to force NM upon people; instead we need to make NM *better* than the existing options so that it's a no-brainer choice. There will always be people that want to tinker and do something else or have so totally crack-rock use-cases that we have no hope of easily supporting them, and that's fine. That's what software is about. Instead, I believe our goal is to make NM useful enough, easy enough, and understandable enough, that people *want* to use NM rather than wading through a bunch of scripts. We don't want to force NM upon people; instead we need to make NM *better* than the existing options so that it's a no-brainer choice. There will always be people that want to tinker and do something else or have so totally crack-rock use-cases that we have no hope of easily supporting them, and that's fine. That's what software is about. I just wish every piece of software was based on a philosophy like that. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hasonzt2@nemi.mork.no
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
Serge writes: > Since tmpfs+swap is mostly slower than regular filesystem And the world is flat. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874nqfn0af@nemi.mork.no
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
Aneurin Price writes: > In anything resembling a 'normal' system (ie. the kind where one might > be using the defaults) I would say that the tmpfs correlation is so > strong as to be very nearly 1:1, and this seems like the crux of the > matter; that is after all the reason that these applications are > failing when /tmp is switched to tmpfs. I agree that's likely for any system using a default disk layout, so my comment was irrelevant for this discussion. I still think that the easy tmpfs resizing (no meta data update, no LVM requirements, can use available space on other file systems) makes it superior for /tmp. But most users won't know that they can do this, so we might need a daemon monitoring /tmp and doing ondemand resizing. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87lijsok60@nemi.mork.no
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
Aneurin Price writes: > (Note that we are talking about applications which fail gracefully > when confronted with ENOSPC, Are we? What's the problem then? > but which are likely to do so more often when the size of /tmp is > restricted.) Yes, but the tmpfs correlation is weak. There is absolutely no guarantee that there will be more space available on the root file system than a default tmpfs. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d355pl0v@nemi.mork.no
Re: Summary: Moving /tmp to tmpfs makes it useless
Serge writes: > 2012/6/10 Adam Borowski wrote: > >>> Some people asked for a thread summary. So here it is. >> Seriously, can't you even read what's written to you? > > Yes, I know it was a biased summary. I think you might start to piss off a few people now... Look at what you are quoting above. You introduced your biased summary like this: "Some people asked for a thread summary. So here it is.". I will refrain from further comments. People can judge for themselves. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87txyjp85k@nemi.mork.no
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
Petter Reinholdtsen writes: > [Bjørn Mork] >> I'd like to add another one: >> >> - a tmpfs is always easy to grow without requiring any special >> preparations. Just add more swap. The swap could be on different >> disks, and could even be files hosted on other file systems. > > This sound very similar to what I am doing already with LVM and online > file system growing. A simple 'lvresize' and 'ext2resize' (or just > debian-edu-fsautoresize for those of us with that tool available) > later the full file systems have more free space again. :) > > Did I misunderstand you? No, but those require LVM and available raw disk space. Swap can always be added without any such preparation. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d359qyxb@nemi.mork.no
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
Petter Reinholdtsen writes: > I've happily been using tmpfs on /tmp/ for probably ten years now, and > can list some more benefits: > > - It allow diskless setups like LTSP to work the same way the default >installation in Debian work. They use read-only NFS-mounted file >systems and a writable tmpfs mounted on /tmp/. > > - It reduces the number of disk writes on a laptop, allowing it to >spin down the disk a bit longer. I'd like to add another one: - a tmpfs is always easy to grow without requiring any special preparations. Just add more swap. The swap could be on different disks, and could even be files hosted on other file systems. Any file system will run out of space given the broken applications mentioned in this thread. tmpfs is the only one which will allow all systems to dynamically add more space, only limited by the available disks. That's why tmpfs should be the default for both new and old systems, unless the administrator has explicitly made a more limited choice. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87lijyqd2l@nemi.mork.no
Re: Moving /tmp to tmpfs makes it useless
Vincent Lefevre writes: > On 2012-05-30 12:08:29 +0200, Josselin Mouette wrote: >> Le samedi 26 mai 2012 à 23:02 +0200, Carlos Alberto Lopez Perez a >> écrit : >> > With "tmpfs on /tmp" you are breaking many applications that assume that >> > they have enough space to write on /tmp like the flash player ( see >> > Debian bug #666096 ) or cdrecord software ( see #665634 ). >> >> Seriously, this is madness. You can’t expect to have “enough” space on >> *any* filesystem. > > I think that the point is that in general, there is more space on > the local disk than on some tmpfs. What I mean is that if /tmp is > on the right partition on the disk, it will have more space than > any reasonable tmpfs. Does that make any difference at all? If an application is unable to handle the out-of-space condition, then it will be unable to handle the out-of-space condition no matter how big the file system is. Increasing the file system size is futile. Fix the bug in the application instead. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fwah96n9@nemi.mork.no
Re: Wheezy release: CDs are not big enough any more...
Timo Juhani Lindfors writes: > Bjørn Mork writes: >> No, you don't. On a default Debian system you need to be a member of >> the "floppy" group. From /lib/udev/rules.d/91-permissions.rules : > > Yeah but you are not a member of that group by default surely? No, that decision should be left to the adminstrator. The point was that you don't need to be root, and you probably never should be when doing something like that (to prevent being only one typo away from disaster). >> You mean that they allow you to burn a CD but not write to a USB >> stick? > > Yes, I understood this was the default. If you put users to floppy group > then remote users can read usb sticks of local users. I fail to see how burning to a local user's CD is any better, but yes, if that is a consideration then they need some system to tie the rights to console access. I believe ConsoleKit and the replacement systemd-loginctl attempts to solve such problems. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fwb0a0fj@nemi.mork.no
Re: Wheezy release: CDs are not big enough any more...
Timo Juhani Lindfors writes:
> Wookey writes:
>> And the USB-stick process is not as simple as it might be because you
>> have to find the HD-media files and then _also_ find an iso image to
>> put on. It's no wonder newbs are still downloading CD/DVD images.
>
> You also need to have root access to some machine to create the USB
> media.
No, you don't. On a default Debian system you need to be a member of
the "floppy" group. From /lib/udev/rules.d/91-permissions.rules :
# default permissions for block devices
SUBSYSTEM=="block", GROUP="disk"
SUBSYSTEM=="block", ATTRS{removable}=="1", GROUP="floppy"
> This means you can't create the installation media at most
> university or library machines unlike with CDs.
You mean that they allow you to burn a CD but not write to a USB stick?
Sounds like they have a support problem which I don't think Debian can
solve for them.
Bjørn
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zk98a480@nemi.mork.no
Re: RFC: OpenRC as Init System for Debian
Uoti Urpala writes: > Machine-specific configuration belongs in /etc. The default behavior of > the tools doesn't. Agree. Copying a large set of default policies into /etc just because they *can* be overridden is not user friendly. And it does not make the defaults any more configuration either. It just hides important local changes and makes it difficult both for the user and the application itself to distinguish between defaults and configuration overrides. A default setting does not count as configuration until it is changed, IMHO. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87397844h3@nemi.mork.no
Re: Removing the MTA from the default install
Josselin Mouette writes: > Is this the right time to do it? Wasn't this just recently discussed? Just replay the thread: http://lists.debian.org/debian-devel/2011/10/msg00227.html Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k40u4s1g@nemi.mork.no
Re: Default display manager should not be gdm3
Josselin Mouette writes: > This feature was in squeeze and so far we didn’t reinstate it in 3.x on > upstream request. This is because they complained people used this > feature to shoot themselves in the foot and then accused gdm of being > broken. So they choose to break gdm and ignore all those now *rightfully* accusing gdm of being broken? That makes no sense at all. I'm not going to call it crazy. It's merely insane. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sjhvdrew@nemi.mork.no
Re: [Long] UEFI support
Tanguy Ortolo writes: > Paul Wise, 2012-01-09 00:44+0100: >> Sounds like he was asking you to name these new 32-bit only x86 >> systems that are still being produced and sold. > > That is right. In fact, I do not doubt there are some 32 bits only > processors sold today, but I am not sure that they are using an UEFI. There are. STFW > It is very possible, but it may not be a very common case. Neither is UEFI on 64bit systems. Yet. So let's just ignore it then. No? Well, then I don't see how the "common case" argument is relevant for 32bit systems either. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878vlhfei7@nemi.mork.no
Re: /tmp as tmpfs and consequence for imaging software
Chow Loong Jin writes: > On 16/11/2011 22:43, Salvo Tomaselli wrote: >>> Most netbooks and small laptops (such as Thinkpads) do not. >> My thinkpad has it... > > Mine doesn't. The smaller Thinkpads (less than 14"?) don't. This discussion is getting more and more weird, but for the sake of continuing it: My Thinkpad X301 has a DVD-burner even if it only has a 13" screen and weighs in at less than 1.5kg. It also has 8GB RAM, to add some more useless numbers. But the last item is non-default.. And BTW, the Sun tmpfs(7fs) man page seems to be last updated in 1990, so the /tmp on tmpfs usage must be older than that. See e.g. http://download.oracle.com/docs/cd/E19455-01/806-0636/6j9vq2bui/index.html Personally I find the whole idea of some application *assuming* anything about where to put multi-GB files ridiculous. You cannot. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87lire95i7@nemi.mork.no
Re: RFC: Making mail-transport-agent Priority: optional
Josh Triplett writes: > What would it take to make this change? Changing the LSB. Or you need to keep the sendmail interface. Which is what mail-transport-agent provides. > Have I missed any important points? You forgot to explain the upside, reason, why, gain, whatever. > Would any other packages need changes, other than the ones I've > mentioned above? all packages with cron jobs, all 3rd party applications assuming an UNIX environment, ++ The reasons are all explained in the release notes. Why not remove syslog as well? I'm pretty sure there are plenty of end users never ever looking at a log file. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871uuhhly0@nemi.mork.no
Re: ifupdown 0.7~alpha4 in experimental
Stephan Seitz writes: > So how do you do the auto configuration? Do you have radvd running or > a DHCPv6 server? If I understand correctly, radvd won’t give you DNS > servers. radvd *can* give you DNS servers. See the RDNSS option in radvd.conf(5). rdnssd is a client implementation for Linux. Other than that, the client support is not very widespread. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k4cmkpo9@nemi.mork.no
