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

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

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

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

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

Accepted netbase 5.5 (source all) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 17 Nov 2018 02:50:53 +0100 Source: netbase Binary: netbase Architecture: source all Version: 5.5 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Description: netbase- Basic TCP

Accepted kmod 25-2 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 17 Nov 2018 01:56:00 +0100 Source: kmod Binary: kmod libkmod2 libkmod-dev libkmod2-udeb Architecture: source amd64 Version: 25-2 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri

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

Accepted whois 5.4.0 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 26 Oct 2018 18:32:49 +0200 Source: whois Binary: whois Architecture: source amd64 Version: 5.4.0 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Description: whois - intelligent

Accepted whois 5.3.3 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 21 Jul 2018 00:14:44 +0200 Source: whois Binary: whois Architecture: source amd64 Version: 5.3.3 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Description: whois - intelligent

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

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

Re: RIchiesta di keysigning

On Oct 21, Gerardo Ballabio wrote: > sto cominciando a contribuire a Debian (vedi bug #898506). C'e' > qualcuno in zona Milano/Monza che potrebbe firmare la mia chiave GPG? Sì, ma dal lato opposto: http://www.wikicloud.it/Datacenter/Milano/Direzioni -- ciao, Marco signature.asc Description:

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 >

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

Accepted usrmerge 19 (source all) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 30 Sep 2018 19:09:42 +0200 Source: usrmerge Binary: usrmerge Architecture: source all Version: 19 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Description: usrmerge - Convert

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

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]

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

Accepted libxcrypt 1:4.1.1-1 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 02 Aug 2018 03:07:49 +0200 Source: libxcrypt Binary: libcrypt1 libcrypt2 libcrypt1-dev libcrypt2-dev libcrypt1-udeb Architecture: source amd64 Version: 1:4.1.1-1 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri

Accepted libxcrypt 1:4.1.0-1 (source amd64) into unstable, unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 19 Jul 2018 11:50:29 +0200 Source: libxcrypt Binary: libcrypt1 libcrypt2 libcrypt1-dev libcrypt2-dev libcrypt1-udeb Architecture: source amd64 Version: 1:4.1.0-1 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri

Accepted inn2 2.6.2-1 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 20 Jul 2018 21:55:50 +0200 Source: inn2 Binary: inn2 inn2-inews inn2-dev Architecture: source amd64 Version: 2.6.2-1 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Description: inn2

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

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

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

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 harder than I t

Accepted tin 1:2.4.2-1 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 20 Jul 2018 00:38:43 +0200 Source: tin Binary: tin Architecture: source amd64 Version: 1:2.4.2-1 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Description: tin- Full-screen

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/Changes

Accepted usrmerge 18 (source all) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 16 Jul 2018 03:58:40 +0200 Source: usrmerge Binary: usrmerge Architecture: source all Version: 18 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Description: usrmerge - Convert

Accepted ladvd 1.1.2-1 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 16 Jul 2018 00:26:03 +0200 Source: ladvd Binary: ladvd Architecture: source amd64 Version: 1.1.2-1 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Description: ladvd - LLDP/CDP

Accepted whois 5.3.2 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 15 Jul 2018 12:38:42 +0200 Source: whois Binary: whois Architecture: source amd64 Version: 5.3.2 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Description: whois - intelligent

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

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

Accepted whois 5.3.1 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 22 May 2018 15:32:28 +0200 Source: whois Binary: whois Architecture: source amd64 Version: 5.3.1 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By: Marco d'Itri <m...

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

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

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:

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

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

Accepted whois 5.3.0 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 21 Jan 2018 01:23:45 +0100 Source: whois Binary: whois Architecture: source amd64 Version: 5.3.0 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By: Marco d'Itri <m...

Accepted kmod 25-1 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 21 Jan 2018 01:02:46 +0100 Source: kmod Binary: kmod libkmod2 libkmod-dev libkmod2-udeb Architecture: source amd64 Version: 25-1 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By:

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

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

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

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

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

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

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. --

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

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

Accepted whois 5.2.20 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 27 Dec 2017 03:15:27 +0100 Source: whois Binary: whois Architecture: source amd64 Version: 5.2.20 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By: Marco d'Itri <m...

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

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

Accepted binkd 1.1a-96-1 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 24 Dec 2017 01:45:58 +0100 Source: binkd Binary: binkd Architecture: source amd64 Version: 1.1a-96-1 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By: Marco d'Itri <m...

Accepted whois 5.2.19 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 10 Dec 2017 17:16:58 +0100 Source: whois Binary: whois Architecture: source amd64 Version: 5.2.19 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By: Marco d'Itri <m...

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.

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

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,

Accepted rblcheck 20020316-10 (source i386) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 26 Nov 2017 12:40:52 +0100 Source: rblcheck Binary: rblcheck Architecture: source i386 Version: 20020316-10 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By: Marco d'I

Accepted inn2 2.6.1-4 (source i386) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 21 Nov 2017 17:22:54 +0100 Source: inn2 Binary: inn2 inn2-inews inn2-dev Architecture: source i386 Version: 2.6.1-4 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By: Marco d'I

Accepted usrmerge 17 (source all) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 05 Nov 2017 19:14:38 +0100 Source: usrmerge Binary: usrmerge Architecture: source all Version: 17 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By: Marco d'Itri <m...

Accepted openbsd-inetd 0.20160825-3 (source i386) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 01 Nov 2017 20:21:23 +0100 Source: openbsd-inetd Binary: openbsd-inetd Architecture: source i386 Version: 0.20160825-3 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By: Marco d'I

Accepted inn2 2.6.1-3 (source i386) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 30 Oct 2017 01:52:26 +0100 Source: inn2 Binary: inn2 inn2-inews inn2-dev Architecture: source i386 Version: 2.6.1-3 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By: Marco d'I

Accepted tcp-wrappers 7.6.q-27 (source i386) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 30 Oct 2017 00:22:41 +0100 Source: tcp-wrappers Binary: tcpd libwrap0 libwrap0-dev Architecture: source i386 Version: 7.6.q-27 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By:

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

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

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

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

Accepted whois 5.2.18 (source i386) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 22 Aug 2017 16:45:02 +0200 Source: whois Binary: whois Architecture: source i386 Version: 5.2.18 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By: Marco d'Itri <m...

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

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

Re: OpenSSL disables TLS 1.0 and 1.1

On Aug 11, Marco d'Itri <m...@linux.it> 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 tha

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

Re: OpenSSL disables TLS 1.0 and 1.1

On Aug 07, Joerg Jaspert wrote: > Thats nice for any environment where on can freely define that > everything works like this. > > Unfortunately real world doesnt work like it. I think that I live in a real enough world (commercial web hosting), and my customers have been

Accepted whois 5.2.17 (source i386) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 27 Jul 2017 17:08:47 +0200 Source: whois Binary: whois Architecture: source i386 Version: 5.2.17 Distribution: unstable Urgency: high Maintainer: Marco d'Itri <m...@linux.it> Changed-By: Marco d'Itri <m...

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

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

Accepted whois 5.2.16 (source i386) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 13 Mar 2017 01:40:38 +0100 Source: whois Binary: whois Architecture: source i386 Version: 5.2.16 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By: Marco d'Itri <m...

Re: Switch default installation image link?

On Jun 06, Steve McIntyre wrote: > For a number of years, we've been linking to the amd64/i386 netinst > installer image from the front page. I think it's time to just switch > that to just an amd64 image for stretch now. The vast majority of the > machines out there are now

Accepted usrmerge 16 (source all) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 31 May 2017 14:37:35 +0200 Source: usrmerge Binary: usrmerge Architecture: source all Version: 16 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By: Marco d'Itri <m...

Re: Bug#862698: ITP: minecraft -- blocks to build anything you can imagine

On May 16, Simon McVittie wrote: > Yes, that's why I suggested Flatpak. It would also be possible to use > a long bwrap command-line - that's what Flatpak does internally. > One day I should try making game-data-packager's games (mostly the quake > family) use bwrap like that.

Re: policy for shipping sysctl.d snippets in packages?

On Apr 23, Wouter Verhelst wrote: > The "packages drop files in /usr/*, sysadmins override in /etc" way of > doing things is prevalent in the RPM world; in Debian, however, we > traditionally have packages drop files in /etc, and let the maintainer While this scheme was

Re: "Ask HN: What do you want to see in Ubuntu 17.10?"

On Apr 05, gregor herrmann wrote: > > Indeed, about every month my Latitude immediately wakes up after > > suspend, and when this happen I can only reboot it because it will keep > > waking up again after every attempt at suspending. > The last time I had this issue, `echo

Re: "Ask HN: What do you want to see in Ubuntu 17.10?"

On Apr 05, Andrey Rahmatullin wrote: > I don't trust Linux enough to put my laptop into the bag not checking that > it is indeed suspended. Indeed, about every month my Latitude immediately wakes up after suspend, and when this happen I can only reboot it because it will keep

Accepted usrmerge 15 (source all) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 21 Mar 2017 23:19:50 +0100 Source: usrmerge Binary: usrmerge Architecture: source all Version: 15 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By: Marco d'Itri <m...

Accepted kmod 24-1 (source i386) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 27 Feb 2017 02:50:32 +0100 Source: kmod Binary: kmod libkmod2 libkmod-dev libkmod2-udeb Architecture: source i386 Version: 24-1 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By:

Accepted inn2 2.6.1-2 (source i386) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 27 Feb 2017 02:28:32 +0100 Source: inn2 Binary: inn2 inn2-lfs inn2-inews inn2-dev Architecture: source i386 Version: 2.6.1-2 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By:

Accepted usrmerge 14 (source all) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 27 Feb 2017 02:03:26 +0100 Source: usrmerge Binary: usrmerge Architecture: source all Version: 14 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By: Marco d'Itri <m...

Accepted whois 5.2.15 (source i386) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 27 Feb 2017 00:37:41 +0100 Source: whois Binary: whois Architecture: source i386 Version: 5.2.15 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By: Marco d'Itri <m...

Re: sane chromium default flags - include --enable-remote-extensions

On Feb 24, Sven Hoexter wrote: > To be honest I've the feeling that we're doing a disservice to our > users when we release stretch with the current defaults. Putting I amazed by this decision: this is the kind of thing that makes people not take Debian seriously. This

Re: convention on listen port local or all network interfaces etc.

On Feb 21, Patrick Schleizer wrote: > At the moment it looks like there is no convention for where server > applications are configured to listen by default, on localhost vs. all > interfaces. Looks like deciding that is up to the upstream author of the >

Re: Bug#843906: tftpd, removal in favour of tftpd-hpa

On Feb 13, Ian Jackson wrote: > I didn't manage to get around to this earlier but I wonder if it would > still be a good idea, even for stretch. Yes please. -- ciao, Marco signature.asc Description: PGP signature

cena italiana a FOSDEM 2017

Qualcuno è interessato a una cena italiana venerdì sera? -- ciao, Marco signature.asc Description: PGP signature

Accepted openbsd-inetd 0.20160825-2 (source i386) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 02 Jan 2017 11:49:56 +0100 Source: openbsd-inetd Binary: openbsd-inetd Architecture: source i386 Version: 0.20160825-2 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By: Marco d'I

Accepted openbsd-inetd 0.20160825-1 (source i386) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 26 Dec 2016 19:18:00 +0100 Source: openbsd-inetd Binary: openbsd-inetd Architecture: source i386 Version: 0.20160825-1 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By: Marco d'I

Accepted inn2 2.6.1-1 (source i386) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 30 Dec 2016 01:21:45 +0100 Source: inn2 Binary: inn2 inn2-lfs inn2-inews inn2-dev Architecture: source i386 Version: 2.6.1-1 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By:

Accepted whois 5.2.14 (source i386) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 29 Dec 2016 23:12:19 +0100 Source: whois Binary: whois Architecture: source i386 Version: 5.2.14 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By: Marco d'Itri <m...

Re: Can we kill net-tools, please?

On Dec 26, Martín Ferrari wrote: > I am currently the Debian maintainer for net-tools, but note that I have > not forked, nor I am developing net-tools. Upstream got active again, > somehow. Thank you for your clarification. I think that we have a consensus about this: can

Re: Can we kill net-tools, please?

On Dec 29, Simon Richter wrote: > As long as there is still a way to have working "netstat" and "ifconfig" > commands, that is fine. I do not think that anybody sane wants to remove the package from the archive: the idea is to stop using it in script in other packages since

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