On Mar 14, Paul Wise wrote:
> AFAICT OnSuccess/OnFailure services don't recieve the output of the
> succeeding/failing service. So the mail sending service needs to dig
> around in the systemd journal. Or make the service output go to a file,
> FIFO or socket and then send that to a mail.
Yes, th
On Mar 11, Simon Richter wrote:
> We currently don't have a good mechanism for leaving configuration behind on
> purge, which we've historically done with user accounts to avoid reuse of
> UIDs that may own resources, so we'd still have to create the declarations
> from a postinst.
While this is
On Mar 06, Lucas Nussbaum wrote:
> I think that we should reduce the number of packages using the 1.0 format, as
> (1) format 3.0 has many advantages, as documented in
> https://wiki.debian.org/Projects/DebSrc3.0 ; (2) this contributes to
> standardization of packaging practices, lowering the bar
On Mar 04, Baptiste Beauplat wrote:
> Looking at your email headers, I would guess that gmail is already doing it.
>
> X-Google-DKIM-Signature: v=1; a=rsa-sha256...
>
> There is somewhat some irony in Gmail blocking email without a DKIM
> signature while they are using a non-standard header tha
On Jan 23, Richard Laager wrote:
> It might be technically possible to build a binary package with different
> versioning, but even if it is: 1) I don't know how, and 2) I'm not sure
> whether that's a good idea, especially compared to the alternatives.
I did it long ago, I think for kmod taking
On Jan 19, Paride Legovini wrote:
> That's what I had in mind, but the other option:
>
> > Another option would be to have src:ntpsec build the bin:ntp dummy
> > package and remove src:ntp entirely.
>
> also looks sensible to me after all. No strong opinion.
I think that this would be better s
On Jan 18, Michael Biebl wrote:
> I think Fedora prefers chrony instead of ntpsec.
Fedora even uses btrfs, so who cares. :-)
The interesting point is that RHEL switched to chrony for RHEL 7.
Also, I want to add that chrony is not just better as a client, but also
as a NTP server.
https://engine
On Jan 17, Bernhard Schmidt wrote:
> What do you think?
chrony is MUCH better since Debian 10, I agree that it should be the
preferred NTP client for when systemd-timesyncd is not enough.
You can definitely spend your time on something more fun and more
useful.
--
ciao,
Marco
signature.asc
On Dec 30, Scott Kitterman wrote:
> I would too. It would be nice if systemd-resolved had some mechanism to
> support this kind of functionality. If you're going to replace resolvconf,
> then you ought to actually replace it.
systemd-resolved is supposed to forward queries to the upstream res
On Dec 10, Marc Haber wrote:
> Is there any way to fire up a pid-1-systemd isntance inside a debspawn
> container, so that the container could have an IP address and run its
> own sshd? Or is there any way to get a login prompt from an already
> running debspawn container?
I am not familiar with
On Nov 18, Zack Weinberg wrote:
> Are you seriously claiming that that phenomenon is not a severity:critical
> bug?
I am seriously claming that whatever you are referring to, if true, is
such a contrived example that does not actually happen in real life
(or at least, it does not happen frequen
On Nov 18, Zack Weinberg wrote:
> And, as it has proven to be a genuinely critical problem, it is also their
No, it has not.
--
ciao,
Marco
signature.asc
Description: PGP signature
On Nov 10, Sam Hartman wrote:
> I'm sorry, but I think the only way in which that horse is dead is that
> no one has proposed patches to dpkg.
Indeed, because the sides of this argument are like three people (one of
them being the dpkg maintainer) versus everybody else.
Since some significant wo
On Nov 08, Simon Richter wrote:
> Yes, but the conversion needs to be performed by dpkg, because the usrmerge
Please kindly stop beating this long-dead horse.
--
ciao,
Marco
signature.asc
Description: PGP signature
On Nov 08, Simon Richter wrote:
> Right now, it is sufficient to preseed debconf to disallow the usrmerge
> package messing with the filesystem tree outside dpkg. Managed installations
> usually have a ready-made method to do so.
This is not really relevant, since the conversion is mandatory.
The
I have been asked to remove from the usrmerge package the debconf
question which asks to confirm the conversion.
Does anybody REALLY believe that it should not be removed?
--
ciao,
Marco
signature.asc
Description: PGP signature
On Oct 18, Sean Whitton wrote:
Thank you: this is great work and, even if it requires maintaining
support for unmerged systems for yet another release, I fully agree with
the results.
> - Debian contributors who are interested in merged-/usr are invited to
> implement a straightforward migra
On Oct 05, John Paul Adrian Glaubitz wrote:
> Could anyone tell me what the proper gbp command is for creating the changelog
This works for me.
md:~ $ cat ~/bin/git-debtag
#!/bin/sh -e
VER="$(dpkg-parsechangelog --show-field Version)"
if [ -z "$VER" ]; then
echo "Could not parse the changelo
On Sep 28, Noah Meyerhans wrote:
Should it be mentioned what the new recommended DHCP server for general
use will be?
> For what it's worth, my preference would be transition to
> systemd-networkd with bookworm.
I think that a good default would be systemd-networkd for servers and
NetworkManag
On Sep 27, John Paul Adrian Glaubitz wrote:
> Not for me, though. Debian has always followed the philosophy to be a
> universal
> operating system, which also meant that we can't (immediately) use all the new
> technologies and features that other distributions or upstream projects
> develop.
I
On Sep 24, Marc Haber wrote:
> But maybe an alternative? I find the partitioning step one of the most
> error-prone and hard-to-use parts of non-trivial Debian installations.
And the preseeding syntax is as powerful as it is inconvenient.
I had not heard of growlight before yesterday, but from wh
On Aug 29, Colin Watson wrote:
> I can see the issue there. Adding another prompt that every Debian user
> will need to consider on upgrade to the next release is pretty
> undesirable, though - I actively try to avoid that in base-passwd
> changes. So maybe the policy violation, i.e. ending up
On Aug 26, Guillem Jover wrote:
> By my definition, these have never been working correctly, but
> semantics I guess.
It is not semantics. You keep saying that countless Debian and Ubuntu
systems are not working correctly, but since this obviously does not
reflect the experience of the owners o
On Aug 18, Simon McVittie wrote:
> I'm not sure whether there's any plan to remove the /bin, /sbin, /lib
> symlinks *ever* - things like /bin/sh are a de facto API, and the
> ELF interpreters like /lib/ld-linux.so.2 are part of their respective
> architectures' interoperable ABIs (to the extent t
On Aug 16, Wouter Verhelst wrote:
> On Fri, Aug 13, 2021 at 07:53:20AM +0200, Marco d'Itri wrote:
> > Implementations with real /bin /sbin /lib* directories and symlink farms
> > are not useful because they would negate the major benefits of
> > merged-/usr, i.e.
On Aug 16, David Kalnischkies wrote:
> Is perhaps pure existence not enough, do I need to provide an upgrade
> path as simple as possible as well?
If you have specific ideas about how the upgrade path could be improved
then I am interested in hearing them.
I think that it is hard to beat "apt in
On Aug 15, Simon McVittie wrote:
> Doing what usrmerge does from a maintainer script is pretty scary from a
> robustness/interruptability point of view. Without my Technical Committee
> hat on, one route that I think should be considered is deferring the
> migration until the next boot and doing
On Aug 13, Guillem Jover wrote:
> Yes, that major benefit that is completely broken by design and
> unsupported anyway, because /etc and /var can also easily get out
> of sync. If you rely on this then you are on your own anyway…
You say so, but it is a fact that in practice it works really well
Implementations with real /bin /sbin /lib* directories and symlink farms
are not useful because they would negate the major benefits of
merged-/usr, i.e. the ability of sharing and independently updating
/usr.
--
ciao,
Marco
signature.asc
Description: PGP signature
On Jul 22, "Barak A. Pearlmutter" wrote:
> People seem pretty worked up over this, but honestly I'm not
> understanding why.
Because they are scared by new things, hence they oppose merged-/usr
(and systemd before that, and udev even before...).
But since they cannot admit that, then they need t
On Jul 19, Marc Haber wrote:
> I am NOT looking forward having to manually convert legacy systems to
> merged /usr and I do sincerely hope that Debian will choose a way to
> get away without throwing away systems that have just a small /, still
> supporting a dedicated /usr as long as it's mounte
On Jul 19, Polyna-Maude Racicot-Summerside wrote:
> So if I get it right...
Except for /boot/, which may be required for technical reasons, there
is no need to further partition your file system unless you actually
have reasons to do it.
> One partiton for /boot
> One partition for /usr
> One
On Jul 18, Stephan Verbücheln wrote:
> On Sun, 2021-07-18 at 11:13 +0200, Marco d'Itri wrote:
> > I link /var/lib/dpkg/ to somewhere in /usr/, and I think that this is
> >
> What? No matter whether we merge “/bin” or not, “/usr” should stay
> read-only.
The dpkg databa
On Jul 18, Simon McVittie wrote:
> If a machine's /usr is not in sync with its /etc and /var, then it is likely
> to work incorrectly: at a minimum, asking dpkg which packages and versions
But in my experience (with shared-/usr containers) this works great as
long as everything is aligned to the
On Jun 10, Helmut Grohne wrote:
> This raises the question of what the desired semantics for `/etc/shells` are.
> Do we want the strict interpretation of the policy to be followed and update
> all those packages to conditionalize their `add-shell` invocations? Or is
Yes.
--
ciao,
Marco
signat
On Feb 06, "Steinar H. Gunderson" wrote:
> mlocate used to be Priority: standard; for some reason that I haven't been
> able to unearth (despite the efforts of several people), there is now an
Probably because long ago it replaced locate from findutils which used
to be standard too.
> release a
On Jan 28, "Daniel S." wrote:
> This image does not provide unfree WiFi firmware.
It is not just about Wi-Fi but also audio, video and wired Ethernet.
> This gives visibility to the actual problem and the only true solution.
There is really no reason to believe that, even with significant
fundi
On Jan 23, Vincent Bernat wrote:
> This is an anecdotical evidence. To my knowledge, it's not possible to
> make a wireless card work without a proprietary firmware. As laptops are
> getting thinner, the Ethernet port is getting away and dongles to get
> port the RJ45 port are not bundled anymore
On Jan 23, Pierre-Elliott Bécue wrote:
> While I appreciate your point, and agree with the rationale behind it
> (having something that works for very recent hardware would be good), I
This is not about "very recent" hardware, it is really about "most
hardware".
> personally find the way you ex
On Jan 21, Julien Cristau wrote:
> So I'd like to raise the priority of ca-certificates from optional to
> at least standard, as a signal that it should be installed on
Good idea: I think that "standard" is appropriate.
--
ciao,
Marco
signature.asc
Description: PGP signature
On Jan 18, Marc Haber wrote:
> Imagine the catastrophal message we're sending by "here is our
> official image, but that one is unlikely to work on your laptop,
> better use this here."
Yes, it would be bad marketing.
But at least we could show users something that works, so that's still
better
On Jan 15, Emanuele Rocca wrote:
> So the current situation is that we make an active effort to produce two
> different types of installation media: one that works for all users, and
> one broken for most laptops. Some sort of FOSS version of an
> anti-feature. Then we publish the broken version
On Jan 02, Matthias Klumpp wrote:
> You wouldn't have to depend on PackageKit, the offline-upgrades stuff
> can be implemented by other tools that aren't PK as well (you could
> pretty much use the same mechanism, with some safeguards to not
> interfere with PK/GNOME). However, ensuring that no s
On Dec 29, Matthias Klumpp wrote:
> For package upgrades, we can already perform so-called "offline
> upgrades", where the system reboots into a smaller systemd target,
> applies all updates and then reboots again into the updated system.
> This is implemented in PackageKit as an option and used
On Dec 29, Ansgar wrote:
> as suggested in [1], I would like to see Debian to move to support
> only the merged-usr filesystem layout. This would simplfy things for
> the future and also address the problem with installing files under
> aliased trees that dpkg has to do for both variants to be s
On Dec 10, Geert Stappers wrote:
> > Obviously, but I am not aware of any such FC/FCoE hardware (not just the
> > network adapters, but also the storages).
> Acknowledge on that problem.
> Do know that it can and must be solved by wallet.
> So do talk with your purchase department.
No, this is b
On Dec 10, Paul Wise wrote:
> Both of these situations sound like things that should get solved by
> rewriting the vendor/O-O-T code and including it in mainline
> Linux/etc, is there any chance of that happening? Or alternatively,
The Fibre Channel drivers ARE all upstreamed, it's just that the
On Dec 10, Joel Wirāmu Pauling wrote:
> is. Binary compat is mostly a thing of the past in modern Rhel due to
> containerization. Container tooling in userspace is one of the reasons RH
Cool narrative, but the reality is a bit more complex than that.
Fibre Channel users need very specific kernels
On Sep 11, Bernd Zeimetz wrote:
> I think its a bit harsh to ask for other ways of authentication.
Maybe it is.
> A DD should be able to enable the mail account and configure procmail
> (or $preferred_other_way) to reject all mails but those from lenovo.
This would be bad for the server, since i
On Sep 02, Mark Pearson wrote:
> You should just be able to register with your debian.org email address to
> get the discount on any Lenovo equipment. Do let me know if any problems.
This is great news, even if I do not live in the USA so this is not
relevant for me at this time.
But you should
On Aug 17, Matthew Ruffell wrote:
> I propose that we restrict access to dmesg to users in group 'adm' like so:
>
> 1) CONFIG_SECURITY_DMESG_RESTRICT=y in the kernel.
Which is already the default for Debian.
> 2) Following changes to /bin/dmesg permissions in package 'util-linux'
> - Owners
On Jul 23, Andreas Tille wrote:
> I was told that DDs can review the rejection mails at
>coccia.debian.org:/srv/ftp-master.debian.org/queue/reject
> but this was somehow hidden knowledge to me and works only for DDs.
Also, not very practical.
I agree that it is a great idea to Cc a WNPP bug i
On Jul 11, Jonas Smedegaard wrote:
> > (Way more people should switch from wpa_supplicant to iwd.)
>
> Difficult when network-manager depends (not recommends) wpa-supplicant:
> https://bugs.debian.org/919619
How to switch to iwd:
apt install iwd
cat << END > /etc/NetworkManager/conf.d/iwd.conf
On Jun 28, Jaime wrote:
> Given that this is guaranteed to fail, isn't it worth "not doing"? Is
> there anyway that I can get dhclient to wait for a successful
> connection *before* sending out any DHCPDISCOVERs? (In the wired
> world, it doesn't make sense to issue a DHCPDISCOVER before plugging
On Apr 30, Alberto Luaces wrote:
> 1. Authentication: salsa.debian.org only admits RSA or ed25519 for SSH —
> that rules out the ECC types provided by the Pro 2, but I wonder if I
> should go for RSA4096 or if something smaller could be faster on the
> hardware while still being decently secure (
On Apr 04, Niels Thykier wrote:
> Some of the technical debt is "doing harm" in the sense that we will
> have work around and deprecated code that linger and slow down our work
> on improving Debian.
You have cited specific issues which cause troubles, which is quite
different from just removing
On Mar 29, Guillem Jover wrote:
> While it's true that we might need to use such pathnames in debian/rules
> or debhelper fragment files (which some might consider ugly), IMO that
> has always felt like a sign that there's something missing in our
> packaging helpers/tools.
If you believe this th
On Mar 24, Russ Allbery wrote:
> (The Rust team is trying the package everything approach with some success
> but is uncovering other limitations in our processes and tools.) But
"Some" success indeed. My personal experience with trying to package
routinator has been awful, and there is still n
On Mar 16, Thomas Pircher wrote:
> Would you consider nvi as an alternative to vim-tiny? It is quite small
Maintainer: Debian QA Group
Installed-Size: 1.605 kB
I think that busybox still wins.
> A user who does a lot of editing will probably install a better editor
> than {vim-tiny,nvi} anyway
On Mar 16, Tomas Pospisek wrote:
> > Agreed: this is a very good idea since I really think that every default
> > install must provide something enough vi-compatible.
> I'd disagree. vi is very newbie unfriendly. OTOH I expect people that
Even if this were true (using vi is one of the most basic
On Mar 16, Simon McVittie wrote:
> `busybox vi` is rather limited, but is reasonable as an editor of last
> resort; busybox is smaller than either nano or vim-tiny; full systems
Agreed: this is a very good idea since I really think that every default
install must provide something enough vi-comp
On Mar 11, Marvin Renich wrote:
> - it has not been mentioned whether systemd provides any facility to
> block starting _all_ services for a period of time (esp when working
> in a chroot), including services that have not been installed at the
> time the hypothetical "block all ser
On Mar 10, Marvin Renich wrote:
> > The modern and simple solution is "systemctl mask", as long as you do
> > not need to care about the 0.6% of systems which do not use systemd.
> > If you are doing this for your own systems then you obviously know if
> > you can rely on systemd or not.
> I do
On Mar 10, jnq...@gmail.com wrote:
> If the policy-rc.d solution is the modern/best/whatever solution, the
No. policy-rc.d is the old solution which was implemented because there
was no better way to implement this with init scripts.
It worked by mandating that maintainer scripts must start and s
On Mar 07, Tomas Pospisek wrote:
> tldr: why is not having a daemon started on install so involved? Can't
> there be a better way?
There is:
# systemctl mask $DAEMON.service
# apt install $DAEMON
That's it. If the package fails to install then file a bug.
> When I duckduckgo "dpkg do not start
On Feb 19, The Wanderer wrote:
> Is there a reason this is all looking to merge /* into /usr/* instead of
> the other way around?
Yes, nicely documented by the links collected here:
https://wiki.debian.org/UsrMerge .
--
ciao,
Marco
signature.asc
Description: PGP signature
On Feb 19, Guillem Jover wrote:
> For any pathname that has been hardcoded a symlink can be used for
> backwards compat, nothing unlike /bin or /sbin here. This looks just
> like a normal bug from a botched transition, nothing special.
Creating symlinks in /bin and /sbin DOES NOT result in a merg
r. (That's a less strong guarantee than
> the one you are probably hoping for.)
We do not just have a consensus, this has also been a fact for a long
time now:
kmod (25-2) unstable; urgency=medium
* Moved the libraries to /usr/lib/. (Closes: #894566)
-- Marco d'Itri Sat, 1
On Feb 16, Simon McVittie wrote:
> To be clear, what Guillem means by "a proper /usr-merged migration"
> here is changing individual library packages, so that the path to their
Everything I suppose, not just libraries.
> I think we have consensus that consolidating all static OS files into /usr
On Feb 17, Wouter Verhelst wrote:
> - Figure out a way for 32-bit binary-only programs to keep working when
> they touch a time_t beyond 2038.
I am sure that around 2035 "time namespaces" or something similar will
be implemented to solve this.
--
ciao,
Marco
signature.asc
Description: PGP
On Feb 15, Guillem Jover wrote:
> > Somebody reported a similar problem about libcrypt.so.1, which moved
> > from /lib/ (provided by libc) to /usr/lib/ (provided by libxcrypt).
> If the problem was with the new pathname disappearing, then that's just
> yet another instance of the usrmerge-via-sy
On Feb 15, Harald Dunkel wrote:
> I am maintainer for mg, currently on salsa. Problem is, upstream
> doesn't release tar balls anymore, but moved the code to github.
I plan to do something like this for ppp, which now has a proper
upstream git repository but no actual releases in a long time:
On Feb 15, Sven Joachim wrote:
> True, but there seem to be a relatively high number of systems where an
> old unowned version of some library is lying around under /lib (possibly
> because the dpkg database became corrupted at some point and so dpkg
> forgot about the file; see the dpkg bug #949
On Feb 11, Arnd Bergmann wrote:
> I agree that changing the i386 port is probably a bad idea at the moment,
> let's see how the armhf port turns out and fix all the bugs first, as this
> is clearly needed anyway. Once there is a working armhf version with
> full time64 user space, there can be a
On Feb 06, Simon Richter wrote:
> I'd expect servers and embedded systems to be vastly underrepresented in
> both of these statistics, but that doesn't mean these use cases are in any
> way uninteresting to the project.
If you want to argue that the adoption of popcon is not uniform among
differ
On Feb 06, Paul Wise wrote:
> FTP servers that default to using /srv/ftp to serve files.
> TFTP servers that default to using /srv/tftp to serve files.
> These also use those dirs as user home directories.
>
> OBS uses /srv/obs for various things.
>
> I wonder if any of these should be changed?
On Feb 06, Svante Signell wrote:
> There are still a large number of
> Debian users opting away from using systemd (and still use Debian, not
> derivatives). And what about non-linux systems?
This is not true: adoption of systemd in buster is larger than 99%.
Other systems will have different def
On Feb 06, Dmitry Smirnov wrote:
> URL: https://github.com/cloudflare/boringtun
> Description: userspace WireGuard implementation in Rust
What is the purpose of having this packaged in Debian? It is at most
a proof of concept, with hardly any improvements since it has been
relea
On Feb 04, Guillem Jover wrote:
> Well, I guess such a new (conditinally selectable) name could be
> coordinated with glibc upstream? Say bump 32-bit ports to use libc6.1?
> (We already have precedent in some ports that do not use the same
> prevalent SONAME, such as libc6.1, libc0.1 and libc0.1.
On Feb 04, Steve McIntyre wrote:
>We'd need to decide exactly which of our 32-bit ports we would want
>to do this path with (probably armhf->arhmft?, maybe
>armel->armelt?, i386->i386t?. mipsel???). Due to the libc6 soname
I agree with Ansgar here: there is no point in rebuilding i386
On Jan 07, Noah Meyerhans wrote:
> is enabled by setting CRON=1 in /etc/default/spamassassin. For users
> running systemd, I'd expect to ship a timer unit that is disabled by
> default, and have them enable it with:
>
> $ systemctl enable spamassassin-daily-maintenance.timer
>
> Any issues wit
On Jan 03, Thomas Goirand wrote:
> Could you please, therefore, tell me what feature is missing? If you
If I am not mistaken then you started arguing that we should consider an
hypothetical alternative implementation with missing features, so maybe
you should explain what may be missing.
> > A
On Jan 03, Thomas Goirand wrote:
> Yes, there's drawbacks in general. However, you *cannot* just say, we're
> going to use the systemd implementation "just because it's the
> refrence", without even giving me some space to at least *TRY* the
As usual this is about much more than you, and I am qui
On Jan 03, Thomas Goirand wrote:
> That's where I don't agree. While it's nice to have such a declarative
> system, I don't think it's reasonable to impose the implementation of
> any change to systemd to all the other init systems.
I do. Good luck persuading the consumers of this API that they s
On Jan 02, Thomas Goirand wrote:
> My proposal is for Debian to standardize on:
> /bin/tmpfiles
>
> and:
> /usr/bin/sysusers
We already have an interface used by many packages, hence I see no
reason to change it.
Actually it is still not obvious to me why Debian would need a second
implementa
On Dec 07, Andrey Rahmatullin wrote:
> > They go from more systemd support to less systemd support in that order,
> > and there are actually big practical differences.
> > But I need to be clear: only choices 1 (B) and 2 (A) will allow Debian
> > to progress like the other major distributions w
On Dec 07, Martin Steigerwald wrote:
> I think you crossed the line between explaining the options and… trying
> to influence the choice of someone else by stating your opinion as a
> fact.
I have no doubts that my fellow debian developers know who I am and can
put my words in the correct pers
On Dec 07, Mo Zhou wrote:
> The rest options, i.e. B A D H G, look nearly the same to me:
> "first tier support for systemd, second tier for others"
> The only difference I noted is the bug severity for non-systemd support.
>
> In which way(s) are options (B, A, D, H, G) different from each ot
On Nov 27, Samuel Henrique wrote:
> TL:DR; What are the drawbacks of providing an rsync udeb (and
You package will be frozen for a longer time before a release.
The technical part is not hard, you just have to build the package
twice: have a look at kmod for a good example.
--
ciao,
Marco
s
On Nov 01, Thomas Goirand wrote:
> Instead of using well understood parameters to adduser, which we've been
> using for decades, and understand well the parameters, systemd provides
Personally I never remember the exact semantics of many adduser/addgroup
parameters and I have to double check the
On Oct 31, Svante Signell wrote:
> When elogind enters testing there would be many more people running
> Debian with sysvinit/elogind. elogind is needed for desktop usage when
> not using systemd as PID 1. And as said numerous times Debian
elogind is already in testing: I will be delighted to see
On Oct 31, Simon Richter wrote:
> However, a lot of our software comes from the BSD world and will never
> fully switch to systemd, and that software is often used in server contexts
> by people who know exactly what they are doing. I don't see why we
> shouldn't support these people anymore, esp
On Oct 31, "Theodore Y. Ts'o" wrote:
> handled on a case by case basis. Exactly how much of a win do we get
> if we use a particular systemd feature in core Debian packaging? How
> hard is it to emulate that for non-systemd systems? I don't think
> that decision can be made in the abstract, un
Package: wnpp
Severity: wishlist
Owner: Marco d'Itri
* Package name: fort-validator
Version : 1.0.0
Upstream Author : NIC MX and LACNIC
* URL : https://nicmx.github.io/FORT-validator/
* License : MIT
Programming Lang: C
Description : An RPKI Vali
On Sep 16, Sam Hartman wrote:
> * Work to understand why people are using Github. From my past
For the same reason why most people are using Twitter instead of
Mastodon: the community and network effect.
This is not a technical problem, so it cannot be solved by Debian.
All my packages are on
On Sep 13, Ondřej Surý wrote:
> > We are talking about preventing large scale censorship (I do not think
> > that this is really about privacy) for *general users*: obviously *we*
> > already know about countless workarounds.
> That’s a false statement. Right now, we are talking about sending _
On Sep 13, Thomas Goirand wrote:
> You shouldn't insist on always writing "their ISP", as if it was the
> only choice. It isn't. One can setup his own recursive DNS locally, for
> example. I've done this for years, as I didn't trust my ISP (first, in
Sure, me too: but it does not matter, because
On Sep 13, Jeremy Stanley wrote:
> Note that by way of counterargument, Google and its services have
> been blocked in mainland China by the Great Firewall for nearly a
> decade now, so I question whether there is really such a thing as
> "too big to block."
This is a false dichotomy: not all nat
On Sep 12, Wouter Verhelst wrote:
> Except all they need to do is return NXDOMAIN on the
> "use-application-dns.net" domain, and Presto! they can spy on their
> users again.
They need to have a government to compel then to do it, which is not
obvious. And then Mozilla will disable that (you can
On Sep 12, Alf Gaida wrote:
> It doesn't really matter. In fact python2 is dead for years, if we
> start now to make a plan we are years to late. The timeframe is _now:.
Dead for who? As long as somebody will be interested in maintaining
python2 it will not be dead.
I maintain some packages whic
101 - 200 of 1926 matches
Mail list logo
