Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

On Sep 09, Adam Borowski wrote: > With DoH: > * the target server knows about you (duh!) > * the ISP can read the destination of every connection > [reading the IP header, reading SNI header] > * the ISP can block such connections > [blocking actual connection] Well, no. They cannot without s

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

On Sep 08, Ondřej Surý wrote: > I would rather see an explicit statement. I would be very surprised > with Debian’s usual stance regarding the users’ privacy that we would > not consider this as a privacy violation, but again I am not Firefox > maintainer in Debian and I would rather hear from

Re: Git Packaging: Native source formats

On Aug 30, Scott Kitterman wrote: > It's not particularly rare for me to poke through other distros package > patches when I'm trying to figure out how to solve a problem. I suspect I'm I would even say that maintainers who do not periodically review what other distributions do with their own

Re: duplicate popularity-contest ID

On Aug 05, Bill Allombert wrote: > Each Debian popularity-contest submitter is supposed to have > a different random 128bit popcon ID. > However, the popularity-constest server > receives a lot of submissions with identical popcon ID, which cause them > to be treated a

Re: tag2upload (git-debpush) service architecture - draft

On Aug 02, Sam Hartman wrote: > In effect, ftpmaster is saying they are uncomfortable trusting > tag2upload very much. A simple solution to this concern would be for ftpmaster to take over the operations of tag2upload once it will be ready. -- ciao, Marco signature.asc Description: PGP sign

Re: default firewall utility changes for Debian 11 bullseye

On Aug 01, Aron Xu wrote: > If there is no pre-installed firewall application in a standard/full > installation (which does not exist for us theoretically), Debian could > be easily marked as missing feature in some enterprise IT evalutation, [citation needed] Even if this were true I do no thin

Re: default firewall utility changes for Debian 11 bullseye

On Jul 31, Aron Xu wrote: > utility (for instance, firewalld) for certain use cases, i.e. it could > be useful for a "standard" server installation with graphic desktop, > for which we could expect most users choosing this method would like > to have advanced firewalling as an enterprise feature

Re: default firewall utility changes for Debian 11 bullseye

On Jul 31, Scott Kitterman wrote: > Please don't install one by default. I suspect it will cause more > trouble for end users than it's worth. Making sure our default > install is severely limited in what ports it listens to is likely more > broadly useful and less risky. Agreed. Default-den

Re: tag2upload (git-debpush) service architecture - draft

On Jul 28, Bernd Zeimetz wrote: > So I think the best thing to do is to get sha256 working in git and > force the usage of sha256 if you want to sign a tag for upload. This cannot be a goal for this project since git upstream will need apparently a few more years for the transition to sha-256 to

Re: Challenge from Julia's non-standard vendored openblas"64_"

On Jul 28, Mo Zhou wrote: > 2. Specifically compile a libopenblas64_.so >from src:openblas for julia's use. >This looks very bad for src:openblas's >package layout. Why would this look bad? We have plenty of source packages which generate multiple variations of binary packages. udebs

Re: seccomp woes (was: file(1) now with seccomp support enabled)

On Jul 20, Christoph Biedl wrote: > * Centralize the list of supported archs in the seccomp packages. By > either creating an empty libseccomp-dev for the archs where seccomp > is not supported, or by creating a "libseccomp-dev-dummy" for these. > In the latter case package maintainers woul

Re: default firewall utility changes for Debian 11 bullseye

On Jul 17, Paul Wise wrote: > To me, something like opensnitch seems like a better option for a > desktop firewall once it becomes more mature and enters Debian. This project is a "personal firewall", which is a quite different thing from what is being discussed here. -- ciao, Marco signatur

Re: Bits from the Release Team: ride like the wind, Bullseye!

On Jul 07, Jonathan Wiltshire wrote: > Q: I already did a binary upload, do I need to do a new (source-only) > upload? > A: Yes (preferably with other changes, not just a version bump). Is there any good reason why we still do not have an interface to allow developers to self-service reques

Re: @debian.org mail

On Jun 03, Daniel Lange wrote: > It is a data point to prove your "we do not have forged email issues" wrong. By "forged email issues" I mean phishing attacks, not garden variety malware which can be blocked in other ways. -- ciao, Marco signature.asc Description: PGP signature

Re: @debian.org mail

On Jun 03, Daniel Lange wrote: > > -all would stop some forged emails, but we do not have forged email > > issues. > We do. 4% of this year's spam in my spam traps have originated as fake > @debian.org. Unfortunately we even nicely relay them as we can't tell This is not a meaningful figure unles

Re: @debian.org mail

On Jun 03, Russ Allbery wrote: > A possibly useful compromise is to do what Marco suggested: publish SPF > records for domains like lists.debian.org, where all the mail is coming > from Debian infrastructure. That can easily be -all. And then at least > we have the option of moving some of the

Re: @debian.org mail

On Jun 03, Sam Hartman wrote: > But more than that, you don't need the SPF record. (Here comes a short lesson on email authentication...) The most useful way to think about SPF and DKIM is that they allow to move reputation considerations for a message from the sender IP address to the sender d

Re: Stalls due to insufficient randomness in cloud images

On Jun 03, Bastian Blank wrote: > Does anyone know what RHEL8 (which should have this problem as well) > does to "fix" this problem? RHEL8 enables by default rngd from rng-tools, which looks much better to me than haveged. -- ciao, Marco signature.asc Description: PGP signature

Re: @debian.org mail

On Jun 03, Daniel Lange wrote: > The default reply for missing wafer confirmation emails (the software > running debconf19.debconf.org) and missing salsa password reset emails is > "check your Spam folder". Debian.org doesn't have a SPF record so mail > submitted from such Debian machines is a bi

Re: Cdbs Features

On May 22, Wouter Verhelst wrote: > I think at this point we can recommend dh, and require debhelper (i.e., > the individual dh_* tools could be required to be part of the build > system, but how they are called can be left to a maintainer's > discretion, with the assumption that "you use dh or p

Bug#929024: ITP: routinator -- An RPKI Validator

Package: wnpp Severity: wishlist Owner: Marco d'Itri * Package name: routinator Version : 0.3.3 Upstream Author : NLnet Labs * URL : https://nlnetlabs.nl/rpki * License : BSD Programming Lang: Rust Description : An RPKI Validator The Routinator

Re: Do we want to Require or Recommend DH

On May 13, Sam Hartman wrote: > As promised, I'd like to start a discussion on whether we want to > recommend using the dh command from debhelper as our preferred build > system. I have already asked this last time, but nobody answered. I use debhelper in all of my packages but I have never switc

Re: fixing debian-security-support upgrades from stretch (for good)

On May 13, Holger Levsen wrote: > So I think this can only be fixed properly (=without asking people to > upgrade to the latest stretch pointrelease but instead allowing upgrades > to buster from *any* stretch pointrelease) by adding a "pre-depends: > debian-security-support (>= 2019.04.25)" to b

Re: native packages? (Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells")

On Apr 15, Sam Hartman wrote: > However if my sources are in git, git is the definitive format for > thinking about things, and the dsc I'm producing is only for the > convenience of the archive, I don't want to deal with an upstream > tarball. Generating an upstream tarball in this case is still

Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"

On Apr 13, Lucas Nussbaum wrote: > TL;DR: see https://trends.debian.net and Nice. I suggest to add a graph detailing: - packages with at least one init script - packages with at least one systemd unit - packages with at least one init script and one systemd unit Also, did I miss the memo about

Re: Debian vs Linux namespaces

On Mar 23, Harald Dunkel wrote: > AFAICS there are several packages that appear to be unaware of / > do not care about containers, e.g. opensmtpd, bind9, apt-cacher-ng, > probably everything using pidof or pidofproc from /lib/lsb/init-\ > functions). I routinely use containers and namespaces with

Re: Namespace for system users

On Feb 09, Sean Whitton wrote: > ISTM to me we have a consensus, at least, that new packages with system > users should use the underscore prefix convention. There isn't a > consensus on what to do about old packages, but Policy can be written in > such a way to refer only to new packages with s

Re: Handling of entropy during boot

On Jan 16, Guido Günther wrote: > There's also jitterentropy-rngd which does the trick but I haven't > looked at the security implications. Nowadays rngd collects jitter entropy, so I would not use something else. -- ciao, Marco signature.asc Description: PGP signature

Re: Json-c library installed into /lib/ instead of /usr/lib/ ... is that relevant anymore?

On Jan 15, Boyuan Yang wrote: > I digged a little bit into it and found out that it was originally due to > upstart that needed it during bootup [2] so the lib should be placed into /lib > according to FHS. However, with upstart disappeared from Debian archive (since > 2016), other init systems s

Re: Handling of entropy during boot

On Jan 13, Sam Hartman wrote: > I recently discovered that Vmware appears to have no virtual RNG > available to the guest at all. AFAIK you are right. > A buster vmware guest will boot but will be unable to start sshd because > of lack of entropy for typically five minutes or so. > A lot of stuf

Re: Handling of entropy during boot

On Jan 09, "Theodore Y. Ts'o" wrote: > x86 systems have a high resolution timer; Rasberry PI's don't. > Furthermore, if libvirt is miconfigured, it should just be fixed (and > better yet, it should be configured to enable virtio-rng, which is > *not* hard). Can you clarify what is the best practi

Re: usrmerge -- plan B?

On Dec 23, Martin Steigerwald wrote: > I think I have seen this with either SLES or RHEL that they created > symlinks for every binary in /bin and /sbin, pointing to the binary in > /usr/bin and /usr/sbin. I did not understand why at the time I have seen > this. Definitely not RHEL, maybe you a

Re: usrmerge -- plan B?

On Dec 23, Guillem Jover wrote: > To me it's always been very clear the only *proper* way to deploy > merged-/usr, is to do the changes to the canonical pathnames on > each relevant package. Even adding compat symlinks, means that dpkg > would know about them, and they'd be temporary anyway for t

Re: usrmerge debian implementation

On Dec 10, d.dob...@tuta.io wrote: > > I have read that debian was struggling with their implementation of > > usrmerge. This is not true. > > How does the symbolic link method bejng employed differ from that of > > gobolinux's "gobohide"? This "gobohide" thing does not actually move the files,

Re: usrmerge -- plan B?

On Dec 04, Russ Allbery wrote: > Does this imply that you're considering adding support for merging /usr > *properly* directly inside dpkg, with all the correct updates to dpkg's > metadata? > > Because that would be an awesome way to fully support this. It would make using dpkg -S a bit easier

Re: Sending using my @debian.org in gmail

On Nov 30, Alexandre Viau wrote: > - https://en.wikipedia.org/wiki/DMARC Among other issues, the BTS is still not compatible with DMARC. -- ciao, Marco signature.asc Description: PGP signature

Re: usrmerge -- plan B?

On Nov 28, "Alexander E. Patrakov" wrote: > Well, the buildd configuration change has been reverted. What worries me now > is that there is a risk not yet mitigated, coming from personal systems of > Debian developers, and we should also check porter boxes. This is not a new problem at all: in my

Re: usrmerge -- plan B?

On Nov 26, Marc Haber wrote: > I would be willing to do this on production systems that can easily be > snapshotted and reverted in no time during an upgrade change, such as > VMs. Unless forced to, I'd rather not touch systems running on bare > metal and would need a restore-from-backup should u

Re: usrmerge -- plan B?

On Nov 26, Ian Jackson wrote: > I could do it. But, frankly, this is quite a lot of work. I think > the work (throughout the Debian ecosystem) to test this properly far > outweighs the minor benefits. I disagree both that simple testing (that you could do with a KVM snapshot as well) would be

Re: usrmerge -- plan B?

On Nov 26, Bjørn Mork wrote: > "Migration is not (easily) reversible" was reported as important in > 2016: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848626 This is not a bug: nothing is misbehaving, so classifying this as wishlist is correct. I even doubt that it would be technically fea

Re: usrmerge -- plan B?

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. After creating again unmerged chroots for the buildds the only bugs left, a

Re: usrmerge -- plan B?

On Nov 24, "Gabriel F. T. Gomes" wrote: > Has this option been given enough attention? It sounds appealing in Yes. I would love to implement a --dry-run mode, but I still need to figure out how much complex it would be and if it could actually cover all cases. -- ciao, Marco signature.asc

Re: individual packages moving binaries from /bin to /usr/bin (was: Re: usrmerge -- plan B?)

On Nov 22, Ansgar Burchardt wrote: > Well, the iptables case is different: those are compat symlinks created > by the package's maintainer scripts, not the /bin -> /usr/bin symlinks > that merged-/usr sets up. Actually iptables is different because it mixes (incorrectly) compatibility symlinks a

Re: usrmerge -- plan B?

On Nov 22, Michael Stone wrote: > Three years ago we were told this was to enable people to optionally do > something, not that all users would be forced to migrate. That's a pretty > substantial change. At this point there is no plan to force anybody to migrate. It has just been argued that it

Re: usrmerge -- plan B?

On Nov 22, Russ Allbery wrote: > I'm stating the advantages of fully converting Debian to merged /usr for > engineering reasons: I don't think the existing optional migration is > going to work very well or be supportable. On this point, I'm > *disagreeing* with the usrmerge maintainer, who hold

Re: usrmerge -- plan B?

On Nov 22, Matthew Vernon wrote: > > In the worst case it will fail explaining that some local change (in > > a directory which should not have been modified by the local admin, BTW) > > needs to be addressed by the local admin and then it can be restarted > > and continue its work. > Could you

Re: usrmerge -- plan B?

On Nov 22, Michael Stone wrote: > That's not actually what happens: the files are still available in the old > location *if and only if the process is fully successful*. If there are any > issues you have a partially migrated system in which the files are *not* > still available in the old locati

Re: usrmerge -- plan B?

On Nov 22, Ian Jackson wrote: > I would also like to point out that change planning is the job of > someone who wants to change something. That includes not only: I planned for everything that I could foresee. I did not think about the buildds issue, but this is hardly the first time that some

Re: usrmerge -- plan B?

On Nov 22, Ian Jackson wrote: > I hear there was a major free software project who accidentally > usrmerged their build systems and discovered that they then built > broken packgaes. And it was quickly fixed, so no big deal. -- ciao, Marco signature.asc Description: PGP signature

Re: usrmerge -- plan B?

On Nov 22, Michael Stone wrote: > Again, how many weren't systems you're responsible for? I have no doubt that > you took care of the problems that you encountered personally when you wrote > the tool. I've seen a lot of problems on systems in the wild that don't No: what I meant is that I did no

Re: usrmerge -- plan B?

On Nov 22, Jonathan Dowland wrote: > Long-running production systems would presumably be running Stable. We > need testing or unstable systems to try usrmerge. I don't think even > reporting on the success of usrmerge on current-Stable¹ would be > necessarily useful. I use merged-/usr without any

Re: usrmerge -- plan B?

On Nov 21, Michael Stone wrote: > How many long-running production systems do you think people have run > usrmerge on? I'd guess close to zero, since there is no advantage whatsoever Actually I have quite a lot personally, with exactly zero problems. On some of them I also enjoy advantages of mer

Re: usrmerge -- plan B?

On Nov 21, Russ Allbery wrote: > I think there are some arguments to be made for just force-merging and > moving on, but they're mostly "tidiness" arguments (letting everyone No, they are not that at all. I have never argued about "tidiness", nor did anybody else that is working to support merge

Re: usrmerge -- plan B?

On Nov 20, Adam Borowski wrote: If you are seriously concerned with the small issuses caused by the transition to merged-/usr then I have a better proposal. Plan C: just stop supporting non-merged-/usr systems since these problems are caused by having to support both, and there is no real bene

Re: Our build system may be broken: /bin vs /usr/bin

On Nov 19, Matthias Klumpp wrote: > I wonder how this was handled on other distributions when they made > the change - even if the change was applied on all systems, there must > have been at least one release where both modes were supported. No, Fedora and RHEL just switched overnight. On Nov 1

Re: Our build system may be broken: /bin vs /usr/bin

On Nov 19, Dirk Eddelbuettel wrote: > GNU R has long been relying on sed, tar, bzip2, ... and many more base > tools. No issues there. Generally looked for in /bin and found there. Actually this is the root problem: policy says that packages should use the $PATH to search for commands, but your

Re: PHP modules only for PHP 7.3 in buster

On Nov 12, bugs-deb...@antipoul.fr wrote: > modules. As far as I know, some applications are not able to run on PHP > 7.3, so supporting PHP 7.2 in buster could be a good idea. This is not going to happen for reasons that have been explained multiple times, even if everybody knows that if you are

Re: no{thing} build profiles

On Oct 24, Jonathan Dowland wrote: > That is sort-of what is happening for neomutt (20171215+dfsg.1-1) > at least, it reports > >sh: 1: gpg: not found This looks like a very clear error message to me. -- ciao, Marco signature.asc Description: PGP signature

Re: no{thing} build profiles

On Oct 23, Tollef Fog Heen wrote: > > I have sympathy with that position, but in which case PGP should be > > disabled by default in the /etc/Muttrc files too. > Wouldn't it make more sense for mutt to just go «oh, no GPG installed, > let's note that there are signatures here, but they can't be v

Re: no{thing} build profiles

On Oct 23, Jonathan Dowland wrote: > Both of Depends and Recommends in this case have drawbacks. It's a > matter of weighing them up and considering their likelyhoods on a case > by case basis. In this case, the maintainer must weigh the experience of > users who may install mutt without gnupg an

Re: Debian Buster release to partially drop non-systemd support

On Oct 20, Paul Wise wrote: > It might be feasible to introduce nosystemd build profiles to Debian > source packages and then create a shed/bikeshed/PPA (once that > infrastructure exists) that contains rebuilds using that build > profile. That would allow Devuan's libsystemd stripping to be > co

Re: PHP Support in Debian

On Oct 17, Holger Levsen wrote: > yes, but when using your repo one has to add your key to the keys apt > trusts, and this is something completly different than using proper > backports. Well... I trust much more Ondrej's archive since over the years it has proven its quality and scope, while ne

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

On Sep 08, Sean Whitton wrote: > The current policy protects maintainers and users of less popular > packages from feeling that their package is less important in Debian, > just because something else that is more popular comes along and happens > to use the same name. Yes, and the I do not think

Re: Q: Packaging headers -> need for -dev package

On Aug 19, Alec Leamas wrote: > For me, it's natural to package this header in a opencpn-dev package. > However, when confronted with a "citation needed"[2] I don't find > anything written on this. I see three possibilities: I think that distributing it would be useful since it would help users

Re: salsa.debian.org maintenance (GitLab 11.1.4 upgrade, external storage migration)

On Aug 13, Jonas Meurer wrote: > To be honest, I don't like the idea of making our infrastructure as a > project rely on closed and proprietary systems like Google Cloud. Isn't > it important to us as a project anymore to run our infrastructure on > free software and under our own control? [1] Su

Re: Questions about packaging systemd unit files

On Aug 05, "Theodore Y. Ts'o" wrote: > 1) Am I right in understanding that after modifying or adding any >systemd unit or timer files, I must run "systemctl daemon-reload"? Yes. > 2) How is this supposed to be done as part of a debian package >install? Should the package maintainer scri

Re: Bug#904019: ITP: libxcrypt -- Extended crypt library for DES, MD5, Blowfish and others

On Jul 20, Guillem Jover wrote: > > And this means that perl (a libcrypt dependency) would be broken between > > 1 and 5 (or maybe 1 and 3): is this ever going to work? > > Given that this new package is going to replace a part of glibc, it > will need to behave as if it was part of the pseudo-

Re: Bug#904019: ITP: libxcrypt -- Extended crypt library for DES, MD5, Blowfish and others

On Jul 20, Philipp Kern wrote: > I think it's odd to say "here, I'm packaging up a replacement for your > library, but I'm not going to coordinate with you" when we are preparing > a (somewhat) coherent distribution, so I don't think that option should > be discarded. (Unless you have a reasonabl

Re: Bug#904019: ITP: libxcrypt -- Extended crypt library for DES, MD5, Blowfish and others

On Jul 20, Philipp Kern wrote: > Make sure that glibc splits out libcrypt into its own package, have libc6 > depend on it and then provide libcrypt1? (Because it's really providing > libcrypt's ABI from another package.) Versioning might be tricky, though. At some point glibc will just stop build

Re: Bug#904019: ITP: libxcrypt -- Extended crypt library for DES, MD5, Blowfish and others

On Jul 18, Marco d'Itri wrote: > Some day it may replace crypt(3), currently provided by glibc: > https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt I tried creating a package which would divert libc's libcrypt, but it appears to be much harde

Bug#904019: ITP: libxcrypt -- Extended crypt library for DES, MD5, Blowfish and others

Package: wnpp Severity: wishlist Owner: Marco d'Itri I intend to package the new version of libxcrypt, which will replace the orphaned libxcrypt source package. Some day it may replace crypt(3), currently provided by glibc: https://fedoraproject.org/wiki/Ch

Re: Bug#899299: libu2f-udev: Post-inst script should make udev reload rules

On Jun 04, Philipp Kern wrote: > Is this synchronous, or does one also need a call to "udevadm settle"? I > had a problem with kpartx where the loop devices were not available > after the package was installed, likely because of a race. I wonder if a Yes, events in udev are asynchronous no matter

Re: [good new]Type 1 font hinting is now free software

On Jun 01, Bastien ROUCARIÈS wrote: > The license choosen by adobe is unfortunalty apache 2 and thus not compatible > with GPL2 only. In which cases this would be relevant? -- ciao, Marco signature.asc Description: PGP signature

Re: RFC: Support for zstd in .deb packages?

On Apr 27, Julian Andres Klode wrote: > Our major use case is cloud initial setup, image building, CI, buildds, all > of which do not require any syncs, and can safely use eatmydata, for example; > hence the enormous speed up. I do not believe that it would be wise to optimize our packaging syste

Re: Bug#895253: ITP: elisa -- Simple music player with a focus on Plasma desktop integration and privacy

On Apr 08, Adam Borowski wrote: > While I need online music services about as much as I need an additional > hole in the head, this raises a good point: why do music players shipped in > Debian default to grabbing lyrics, "LastFM stats", tags, and what not, even > when playing local media? Probab

Re: interpretation of wontfix

On Mar 28, Simon McVittie wrote: > Is this how most people interpret wontfix? I'd usually interpreted it as > an indication of policy rather than priority: "I acknowledge that this > is a bug, but it isn't going to change, even if you provide a patch". This is how I see it: keeping the bug around

Re: Extended Long Term Support for Wheezy

On Feb 21, Antonio Terceiro wrote: > Maybe the proposal needs to be clarified, but my understanding was that > some companies are willing to fund a longer LTS for a restricted set of > packages and architectures¹, but that the product of that would continue > to be available for anyone. Indeed. I

Re: Reducing the attack surface caused by Berkeley DB...

On Jan 25, Lionel Debroux wrote: > Several days ago, jmm from the security team suggested that I start a > discussion on debian-devel about Berkeley DB, which has known security > issues, because doing so may enable finding a consensus on how to move Can you clarify the threat model? E.g. is libd

Re: Bug#886238: Please introduce official nosystemd build profile

On Jan 07, Thomas Goirand wrote: > > duplicates that code. The correct response to a patch to build without > > libsystemd is "no, that's what libsystemd exists for". > Does this approach also work for non-Linux ports? Yes, as long as somebody would bother to update the libsystemd-dummy package.

Re: Bug#886238: Please introduce official nosystemd build profile

On Jan 06, Simon Richter wrote: > As it is now, we have a lot of people who are maintaining their own > packages outside of Debian. Can we get enough support to reintegrate > both the people and the code? I will ignore for the time being the reasons why these packages are outside of Debian, and

Bug#886238: Please introduce official nosystemd build profile

On Jan 04, Hleb Valoshka <375...@gmail.com> wrote: > "anti-systemd zealots" Steve, when did you join LP fanclub? When > Ubuntu decided to throw away your upstart and use systemd instead? Classy... > Do we have runtime systemd detection in all software linked against > libsystemd so it will work p

Bug#886238: Please introduce official nosystemd build profile

On Jan 03, Andrew Shadura wrote: > Do we really need systemd-less builds? I'm not convinced this is > something relevant to Debian. Not at all. This would be a lot of work for the benefit of a tiny audience: the disturbed people who hate systemd so much that they cannot accept even that libsyst

Re: Is missing SysV-init support a bug?

On Dec 31, Simon Richter wrote: > > There are some cases when using sysvinit is preferred over systemd. [...] > These are running stretch, and I would like to upgrade them without > breaking my existing scripts, which assume sysvinit with runlevels > (including one-shot runlevels). Somebody havin

Re: Is missing SysV-init support a bug?

On Dec 30, Alex Mestiashvili wrote: > AFAIK there is no way drop some capabilities with systemd geared linux > containers while it is possible with sysvinit. Here it is: no CAP_SYS_ADMIN. # cat /etc/systemd/nspawn/secure.nspawn [Exec] DropCapability=CAP_AUDIT_CONTROL CAP_MKNOD CAP_NET_RAW CAP_S

Re: salsa.debian.org (git.debian.org replacement) going into beta

On Dec 30, Alexander Wirt wrote: > > Anyway, looking forward to your map thing :-) > First draft is on https://salsa.debian.org/salsa/AliothRewriter Can you first apply some regexp-based mappings, like collab-maint to Debian? This would automatically solve most cases. -- ciao, Marco signatur

Re: salsa.debian.org (git.debian.org replacement) going into beta

On Dec 29, Alexander Wirt wrote: > Please propose a solution for reusing the name without breaking renamed and > not yet migrated repos. Ignore the renamed repositories: if somebody renamed them then they obviously expected to have to update the VCS URLs anyway. Switch the anonscm name when ali

Re: udftools, pktsetup and init scripts

On Dec 28, Pali Rohár wrote: > I think it could make sense to remove init script and replace it by new > udev rule and move both (udev rule and pktsetup) into own binary package > pktsetup. Yes: udev is de facto mandatory nowadays if you have anything dynamic, so do now waste time with boot time

Re: salsa.debian.org (git.debian.org replacement) going into beta

On Dec 26, Alexander Wirt wrote: > Unfortunately that is something that has to be done. At least unless someone > wants to write some kind of redirection map. I am really surprised that this issue was not considered: I expect that git hosting is by far the most common use case for alioth. --

Re: salsa.debian.org (git.debian.org replacement) going into beta

On Dec 25, Alexander Wirt wrote: > Every user can create projects in their own namespace (similar to GitHub). What about git repository URLs? I am not looking forward to update all Vcs-Git and Vcs-Browser headers currently referencing anonscm.debian.org. -- ciao, Marco signature.asc Descript

Re: Debian Stretch new user report (vs Linux Mint)

On Dec 04, Michael Lustfield wrote: > As long as I avoid Nvidia, I usually have excellent luck finding systems > (specifically laptops) that work well without anything from non-free. With > servers, I usually need something for the networking drivers but nothing else. Looks like you are confused.

Re: Debian Stretch new user report (vs Linux Mint)

On Dec 04, Russ Allbery wrote: > +1. I think firmware is something conceptually different than non-free > software in general, and it would be good to give users a simple way to > choose to enable non-free firmware without enabling other non-free > software. Me too. Mostly everybody believed thi

Re: recommends for apparmor in newest linux-image-4.13

On Nov 28, Christoph Hellwig wrote: > It's just a bad idea of a security model that implements ad-hoc > and mostly path based restrictions instead of an actually verified > security model. Using that by default makes it much harder to actually > use a real MAC based security model, which not onl

Re: [Pkg-javascript-devel] Bug#877212: node-d3-color: B-D npm not available in testing

On Oct 03, Gunnar Wolf wrote: > So, contrib is _explicitly_ meant for software that does not meet the > DFSG, not for random stuff that cannot be packaged for convenience or > different issues. I am almost sure that when I joined the project contrib was also the place for sub-standard packages.

Re: New httpd-fastcgi virtual package

On Sep 19, Xavier wrote: > So FastCGI application could have dependency on it. How would this work? The packages that could use it would still need to ship a configuration file for every web server since there is no common API like /usr/lib/cgi-bin/ . -- ciao, Marco signature.asc Descriptio

Re: Summary of the Arm ports BoF at DC17

On Sep 14, Steve McIntyre wrote: > The Pine64 [6] is another alternative, based on a mobile CPU. It's > therefore got limited RAM and I/O. Upstreaming has taken a while, but > is getting there in current kernel releases. U-Boot head will work on > the board, including the UEFI implementation ment

Re: Steps towards a patch to document disabling a daemon upon installation

On Sep 09, Sean Whitton wrote: > 1. Is the 'should not' for the /etc/default practice too strong? I No, because it cannot be supported in a sane way by systemd units. It should even be "must not". -- ciao, Marco signature.asc Description: PGP signature

Re: OpenSSL disables TLS 1.0 and 1.1

On Aug 16, Adrian Bunk wrote: > The only thing you would achieve would be to force people to move > away from Debian to distributions that are still able to interact > with devices running ancient and highly insecure Android firmwares. +1 -- ciao, Marco signature.asc Description: PGP signatur

Re: Whether remotely running software is considered "software" for Debian.

On Aug 12, "Dr. Bas Wijnen" wrote: > Which would be a great example of software that is free interacting with > software that is non-free. Thus the package with this as its main purpose > should live in contrib. There's nothing wrong with that. There is no such requirement for Debian packages a

Re: OpenSSL disables TLS 1.0 and 1.1

On Aug 11, Marco d'Itri wrote: > but I see on your link that Android pre-5.x still has a ~25% market > share, so unless it will drop a lot in the next year I do not think that > we can cut them off from Debian-based web servers. OTOH if the PCI council says that TLS < 1.2

Re: OpenSSL disables TLS 1.0 and 1.1

On Aug 09, Sven Hartge wrote: > Looking at https://developer.android.com/about/dashboards/index.html > there is still a marketshare of ~25% of smartphones based on Android 5.0 > and 5.1 and 16% based on 4.4. So this change would (at the moment) block > ~40% of Android smartphones from connecting

<    1   2   3   4   5   6   7   8   9   10   >