Re: Replacing isc-dhcp-client with dhcpcd-base (Was: ifupdown maintenance)

om the kernel RA implementation. > Thoughts? Agreed, the less surprises here, the better. -- Henrique de Moraes Holschuh

Re: Debian openssh option review: considering splitting out GSS-API key exchange

links to the libc and that's it... And that benefits everything that links to TCP wrappers... I also like to have the (old-school) standard extra layer of protection that libwrap can provide. I'd like to find a way to keep it useful for sshd. -- Henrique de Moraes Holschuh

Re: xz backdoor

d a VM though, when stable + container is not enough. -- Henrique de Moraes Holschuh

Re: Populating non-free firmware?

(maintainer: Henrique de Moraes Holschuh) > - amd64-microcode (maintainer: Henrique de Moraes Holschuh) Please email me directly when it is time to do such upload changing the archive section. I assume we (maintainers) don't need to do the usual dance of opening a bug to change the

Re: Bug#987980: ITP: infamous-plugins -- Infamous Plugins is a collection of open-source LV2 plugins

thing else more suitable... After all, lv2 is not the only thing with infamous plugins out there ;-) -- Henrique de Moraes Holschuh

Re: Bug#982945: ITP: asyncfuture -- Enhanced Qfuture (Qt) interface

Wookey, > Description : Enhanced Qfuture (Qt) interface > > AsyncFuture is designed to enhance the QFuture function, removing.. Maybe this should be prefixed with qt- since it is qt-specific and otherwise somewhat a generic naming? -- Henrique de Moraes Holschuh

Re: Making Debian available

whole. That FAQ entry neither explains things well enough, nor is it very helpful. It could use an update... Heck, I am not even sure the installer could use anything in that non-free CD set to actually load non-free firmware at *install time* (as opposed to installing it to be available on the final system after a reboot) without a lot of manual intervention... -- Henrique de Moraes Holschuh

Re: Release status of i386 for Bullseye and long term support for 3 years?

ral workloads. But I am fine keeping the status-quo of current i686 baseline as well: requiring SSE2 would kick out a non-trivial number of non-Intel processor models, I think we went over this the last time a "i386" baseline bump was considered. -- Henrique de Moraes Holschuh

Re: Pybliographer

tps://wiki.debian.org/RFP And include the explanation above. -- Henrique de Moraes Holschuh

Re: freepats (was: Re: Intend to remove obsolete debhelper compat levels 5 and 6 before the release of bookworm (bullseye + 1)

On Sat, 11 Jul 2020, Henrique de Moraes Holschuh wrote: > On Sat, 11 Jul 2020, Niels Thykier wrote: > > This is a heads up about my intention to remove debhelper compat levels > > 5 and 6. This is also an intention to do a MFB for this removal now at > > ... > > >

freepats (was: Re: Intend to remove obsolete debhelper compat levels 5 and 6 before the release of bookworm (bullseye + 1)

On Sat, 11 Jul 2020, Niels Thykier wrote: > This is a heads up about my intention to remove debhelper compat levels > 5 and 6. This is also an intention to do a MFB for this removal now at ... > Henrique de Moraes Holschuh >freepats Oh wow, I haven't looked at this pack

Re: Bug#964265: ITP: exfatprogs -- tools to create, check and label exFAT filesystems

On Sun, 05 Jul 2020, Andrei POPESCU wrote: > On Sb, 04 iul 20, 19:56:45, s...@stormbind.net wrote: > > While fuse-exfat can be coinstalled at any moment exfat-utils and > > exfatprogs will for now conflict with each other. > > Isn't this the typical use-case for alternatives? It depends. Are the

Re: moving mg from salsa to github?

On Sat, 15 Feb 2020, 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. > No tags. > > How can I tell Salsa? Should I drop the upstream and pristine-tar > branches on Salsa and integrate the rep

Re: Vital fix to console-common stuck in testing for three months

On Mon, 16 Dec 2019, Oskar Berggren wrote: > This was reported in August 2019 as a grave bug: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935096 > > It was fixed early September in 0.7.91 and migrated to testing 2019-09-13: > https://tracker.debian.org/pkg/console-common > > Sadly, this f

Re: Programs contain ads - acceptable for packaging for Debian?

On Thu, 20 Jun 2019, Samuel Thibault wrote: > Bagas Sanjaya, le jeu. 20 juin 2019 20:16:08 +0700, a ecrit: > > On 20/06/19 20.11, W. Martin Borgert wrote: > > > Quoting Bagas Sanjaya : > > > > Such ads is displayed only when users have Internet connection, and > > > > there is no way to patch ZZZ i

Re: Official non-official Debian backporting versioning scheme

On Tue, 21 May 2019, Scott Kitterman wrote: > In Debian we use version-revision (where revision is sometimes complex for > backports and stable updates). If you use version-~revision where revision > is > some thing similar to, but different than that used for security updates, > stable update

Re: Golang >= 1.12 in Buster?

On Mon, 15 Apr 2019, Thomas Goirand wrote: > On 4/15/19 9:24 AM, Hideki Yamane wrote: > > On Sun, 14 Apr 2019 21:11:09 +0200 > > "Dr. Tobias Quathamer" wrote: > >> I think it's the right decision of the release team to stick with golang > >> 1.11 for buster. The previous migration from golang 1.10

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

On Mon, 13 Aug 2018, Alexander Wirt wrote: > We don't rely on it. There will be a backup on debian infastructure so that > we will be able to change to different providers at every time. ... > But using gce allows us to to support use cases different use case than just > git (like lfs, build arti

Bug#904917: general: Gnome randomly crash and restart to login.

On Sun, 29 Jul 2018, Riccardo Gagliarducci wrote: > on Lenovo laptop ideapad 520 Gnome randomly crash and, after some seconds of Are you using the latest version of the ideapad 520 firmware (BIOS/UEFI and EC) ? If not, please upgrade it. -- Henrique Holschuh

Re: Research survey: Impact of Microsoft Acquisition of GitHub

On Fri, 13 Jul 2018, Dominik George wrote: > > I don't think categorizing these things as spam is the right thing to do > > -- although ignoring them most of the time is. > > If they don't care enough about privacy and free software before doing a > survey in a privacy and free software community

Re: Systemd dependencies

On Mon, 26 Feb 2018, Roberto C. Sánchez wrote: > On Mon, Feb 26, 2018 at 11:53:27AM +0100, Bastian Blank wrote: > > On Mon, Feb 26, 2018 at 11:13:03AM +0100, Michael Meskes wrote: > > > > However I really would start one step before. What exactly do you > > > > think > > > > a service dependency o

Re: Debian part of a version number when epoch is bumped

On Wed, 14 Feb 2018, Vincent Bernat wrote: > ❦ 14 février 2018 12:53 +0100, Wouter Verhelst  : > >> > Would it hurt to take those epoch bumps into Debian? > >> > >> Depends on what you mean by hurt. I see epochs being used w/o much > >> tought or care, on many situations where they are not suppos

Re: Summary of the 2038 BoF at DC17

On Sat, 02 Sep 2017, Steve McIntyre wrote: > Massive numbers of libraries are going to need updates, possibly more > than people realise. Anything embedding a time_t will obviously need > changing. However, many more structures will embed a timeval or > timespec and they're also broken. Almost anyt

Re: X facts about Debian - some fact checking and looking for ideas.

On Mon, 28 Aug 2017, shirish शिरीष wrote: > It would be helpful if somebody has one of the 1996 packages snapshots > and can share how the changelogs were at that point of time. That > might give a bit of reference as to how things were and if there were > any changes between them and now. http://

Re: Call for volunteers: FTP Team

On Thu, 17 Aug 2017, Joerg Jaspert wrote: > On 14767 March 1977, Jonathan Carter wrote: > >> it has been quite a while since the last call for volunteers, so here is > >> an update: Yeah, we still need people, and we want you. Well, that is, > >> if you are a Debian Developer, for this. If you are

Intel Skylake/Kaby Lake Hyper-threading bug update

TL;DR: Intel has issued public microcode updates in 2017-07-07, fixing the hyper-threading errata on every affected processor. These updates have been included in the stable and oldstable point releases from 2017-07-22. The microcode updates in the "intel-microcode" packages with the base version

Re: Naming of network devices - how to improve it in buster

On Sat, 15 Jul 2017, Adam Borowski wrote: > > This will match any interface that has MAC address 01:23:45:67:89:ab, > > and will use the "foo" stanzas to configure it. > > Awesome! This sounds like the best solution so far. It is indeed Very Cool, but it might not solve one little thing: iptable

Re: Naming of network devices - how to improve it in buster

On Fri, 14 Jul 2017, Tom H wrote: > > I've never seen the kernel vary the order it enumerates a PCI bus. It doesn't, the last time it changed was on 2.4->2.6. OTOH, *driver probe* ordering can and does change, especially when device probes are being done in parallel. It is best to not get bus en

Re: Naming of network devices - how to improve it in buster

On Wed, 12 Jul 2017, Michael Biebl wrote: > Am 12.07.2017 um 18:58 schrieb Matt Zagrabelny: > > On Wed, Jul 12, 2017 at 11:47 AM, Michael Biebl > > wrote: > > > > Am 12.07.2017 um 17:35 schrieb Marc Haber: > > > My finger memory will still type tcpdump -i eth0 bef

Re: Corruption in CPU

On Tue, 27 Jun 2017, Armin Avdic wrote: > Hello, I saw your article on corrupted data and I have reason to believe > that the bad code goes as far back to Intel Pentium D processors, in my The Intel Pentium D is a very old processor, and its hyper-threading is very different from the recent proces

Re: [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading

(updated perl script, it now needs the "liblist-moreutils-perl" package) On Sun, 25 Jun 2017, Henrique de Moraes Holschuh wrote: > On Sun, 25 Jun 2017, Henrique de Moraes Holschuh wrote: > > This warning advisory is relevant for users of systems with the Intel > > proce

Re: [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading

(updates, hopefully the last ones...) On Sun, 25 Jun 2017, Henrique de Moraes Holschuh wrote: > Fast-forward a few months, and Mark Shinwell noticed the mention of a > possible fix for a microcode defect with unknown hit-ratio in the > intel-microcode package changelog. He matched

Re: [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading

On Mon, 26 Jun 2017, Holger Levsen wrote: > Are there any other public bug reports which got fixed by this, or is the > ocaml issue the only known issue which gets fixed by installing this microcode > update? As far as I know, so far OCaml is the only one that was verified to be caused by the SKL1

Re: [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading

r the inconvenience. On Sun, 25 Jun 2017, Henrique de Moraes Holschuh wrote: > Once you know your processor model name, you can check the two lists > below: > > * List of Intel processors code-named "Skylake": > http://ark.intel.com/products/codename/37572/Skylake > &g

Re: [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading

For the record: the email with the perl script doesn't contain malware. The "malware" alert came from an extremely badly configured system that violates every best practice in the field: it sends email to every original recipient (and not just to local users), and it FORGES its headers to look lik

Re: [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading

On Sun, 25 Jun 2017, Henrique de Moraes Holschuh wrote: > This warning advisory is relevant for users of systems with the Intel > processors code-named "Skylake" and "Kaby Lake". These are: the 6th and > 7th generation Intel Core processors (desktop, embedded, mobi

[WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading

This warning advisory is relevant for users of systems with the Intel processors code-named "Skylake" and "Kaby Lake". These are: the 6th and 7th generation Intel Core processors (desktop, embedded, mobile and HEDT), their related server processors (such as Xeon v5 and Xeon v6), as well as select

Re: Please add lzip support in the repository

On Fri, 16 Jun 2017, Adrian Bunk wrote: > On Thu, Jun 15, 2017 at 08:36:48PM -0300, Henrique de Moraes Holschuh wrote: > >... > > We pretty much need Debian packages to be 100% correct in the first > > place, they are not going to be subject to lossy recovery from > >

Re: Please add lzip support in the repository

On Thu, 15 Jun 2017, mariabi...@gmail.com wrote: > PS: lzip version available in Debian is 1.16, but the last one is 1.19. Maybe > it's time to update! :) lzip 1.19 is available just in Debian experimental, because we are in final-countdown nearly-absolute freeze: we will release the next Debian

Re: Please add lzip support in the repository

On Thu, 15 Jun 2017, Christoph Biedl wrote: > Also I doubt the reduced disk space and network bandwitdth usage of any > new kid on the block (there's also zstd) really justifies the work > needed to implement the support in the many tools that deal with the > files. I might be convinced otherwise.

Re: Too many Recommends (in particular on mail-transport-agent)

On Mon, 12 Jun 2017, Anthony DeRobertis wrote: > Of course—for the under 100K being saved here, only Rube Goldberg would > approve. It is a bit less than 1MiB saved on an AMD system when you purge intel-microcode, but even that is likely to not be considered worth the cost of the extra (empty) cpu

Re: DEP 15: Reserved namespace for DD-approved non-maintainer changes

On Sun, 11 Jun 2017, Sean Whitton wrote: > Henrique de Moraes Holschuh writes: > > > Not just that. If it is for NMUs, one also has to ensure it matches > > what got uploaded (regardless of method: NMU patch, PR, branch...). > > I'm not sure what you're

Re: DEP 15: Reserved namespace for DD-approved non-maintainer changes

On Fri, 09 Jun 2017, Tollef Fog Heen wrote: > > Per the DEP: > > > > > it is very useful for a maintainer to know that a change has been > > > approved by someone who has been trusted by the project with the > > > technical ability to NMU the package > > > > This would be much more cumbersome to

Re: Switch default installation image link?

On Tue, 06 Jun 2017, Adam Borowski wrote: > No one installs i386 new -- machines that are non-amd64-capable are: > * mainstream machines from 2004 and earlier That date is incorrect. I can't give you a precise date, but the Thinkpad T43 with a 32-bit Centrino Pentium-M was **launched** in April/2

Re: Too many Recommends (in particular on mail-transport-agent)

On Fri, 02 Jun 2017, Anthony DeRobertis wrote: > On 06/01/2017 01:00 PM, Henrique de Moraes Holschuh wrote: > >Anything on the top three priorities (critical, alert and emergency) is > >supposed to be displayed immediately to all logged-in users (including > >remote

Re: Too many Recommends (in particular on mail-transport-agent)

On Thu, 01 Jun 2017, Anthony DeRobertis wrote: > On May 31, 2017 3:51:33 AM EDT, Simon McVittie > wrote: > >Can't it report this via the system log? (syslog, systemd-journald) > > The kernel already does, but of course the system log has a lot of > messages, every several seconds on some systems

Re: Too many Recommends (in particular on mail-transport-agent)

On Wed, 31 May 2017, Adam Borowski wrote: > Thus, axing this dependency or degrading it to Suggests would be probably a > good idea. And there's hundreds if not thousands of Recommends of this kind > that need to be looked at -- this example is just more prominent as it > affects every Debian syst

Re: Machine Parsable Release Information Specification

On Fri, 05 May 2017, Benjamin Drung wrote: > I am sending this mail to the development list of the distributions > CentOS, Debian, Fedora, openSUSE and Ubuntu. I am working for > ProfitBricks and we provide public images in our cloud for these > distributions. > > Currently I know no way to retrie

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

On Sun, 23 Apr 2017, Evgeni Golov wrote: > Both, procps and systemd support (/usr)?/lib/sysctl.d/*.conf, however only > one package (systemd-coredump) uses it, all others drop files in > /etc/sysctl.d. Please drop it in /etc, debhelper/dh should mark it as conffile and everything will work. Alter

Re: changelog practice, unfinalised vs UNRELEASED vs ~version

[2] asks for changelog-updating commits before release (or maybe at the tip of every ready-for-integration branch, etc), but... [1] refer to dpkg-mergechangelogs(1) for the git driver for debian/changelog, for example. [2] as in "less busywork" while hacking, and no weird (and possibly maintenance-hell-creating) disparity from commit log contents to in-tree changelog contents. -- Henrique de Moraes Holschuh

Re: manpages.debian.org has been modernized!

On Wed, 18 Jan 2017, Michael Stapelberg wrote: > https://manpages.debian.org has been modernized! We have just launched > a major update to our manpage repository. What used to be served via a > CGI script is now a statically generated website, and therefore > blazingly fast. Oooh, nice! A big tha

Re: Installing missing conffiles (was Re: dpkg no longer installs conffiles??)

On Wed, 30 Nov 2016, Guillem Jover wrote: > On Tue, 2016-11-29 at 19:18:41 +0100, Simon Richter wrote: > > To force reinstallation of configuration files, invoke dpkg with the > > "--force-confmiss" option when installing. This will only restore > > missing configuration files, but not overwrite ch

Re: Difference in behaviour between pbuilder and sbuild

set and exported inside debian/rules. -- Henrique de Moraes Holschuh

Re: OpenSSL 1.1.0

On Thu, 24 Nov 2016, Adrian Bunk wrote: > On Wed, Nov 23, 2016 at 11:50:12PM -0200, Henrique de Moraes Holschuh wrote: > > On Thu, 24 Nov 2016, Kurt Roeckx wrote: > >... > > > > So, if Qt *ever* exposes its use of openssl anywere in its APIs, it > > > > migh

Re: OpenSSL 1.1.0

On Thu, 24 Nov 2016, Kurt Roeckx wrote: > I've always had the impression that there are or used to be > probems using using dlopen()/dlsym(). Maybe related to some things > like RTDL_GLOBAL that causes the symbol lookup to go to the wrong > library. Do you know of any problems related to that? AFA

Re: OpenSSL 1.1.0

of openssl anywere in its APIs, it might not be safe. If it doesn't (i.e. at most you have a qt flag that says "use SSL", etc), then it should be fine. -- Henrique de Moraes Holschuh

Re: libc recently more aggressive about pthread locks in stable ?

On Thu, Nov 17, 2016, at 12:12, Adrian Bunk wrote: > On Thu, Nov 17, 2016 at 11:38:46AM -0200, Henrique de Moraes Holschuh > wrote: > > On Thu, Nov 17, 2016, at 09:50, Adrian Bunk wrote: > > > But we do already have > 1 year of widespread testing by users > > > run

Re: libc recently more aggressive about pthread locks in stable ?

stepping Y0 -- BDE85 fixed by up-to-date microcode). Also, Broadwell-EN/EP/EX (Core Extreme 5th gen, Xeon E5v4 and E7v4) are not blacklisted, either. -- Henrique de Moraes Holschuh

Re: libc recently more aggressive about pthread locks in stable ?

On Thu, Nov 17, 2016, at 09:11, Lucas Nussbaum wrote: > On 17/11/16 at 08:31 -0200, Henrique de Moraes Holschuh wrote: > > The deal with *current* Debian stable is that, if the breakage is too > > widespread, we simply might not be able to do the right thing (fix the > > real

Re: libc recently more aggressive about pthread locks in stable ?

On Sun, Nov 13, 2016, at 14:42, Lucas Nussbaum wrote: > On 12/11/16 at 18:51 -0200, Henrique de Moraes Holschuh wrote: > > Thanks for trying a build run with TSX enabled. > > > > On Sat, 12 Nov 2016, Lucas Nussbaum wrote: > > > I did an archive rebuild on Amazon E

Re: libc recently more aggressive about pthread locks in stable ?

On Wed, Nov 9, 2016, at 06:26, Lucas Nussbaum wrote: > On 08/11/16 at 16:01 -0200, Henrique de Moraes Holschuh wrote: > > I fear it might be bad, but > > I would love to be pleasantly surprised that people did get libpthreads > > locking right most of the time... > &

Re: libc recently more aggressive about pthread locks in stable ?

Lucas, Thanks for trying a build run with TSX enabled. On Sat, 12 Nov 2016, Lucas Nussbaum wrote: > I did an archive rebuild on Amazon EC2 using m4.16xlarge instances, that > use a CPU with TSX enabled. What microcode revision is that Xeon E5-2686 running? > I've filed bugs for the packages tha

Re: client-side signature checking of Debian archives (Re: When should we https our mirrors?)

On Fri, 11 Nov 2016, Christoph Biedl wrote: > a proof of concept for all this (I can resist, though). The apt programs > could obfuscate their request behaviour, the TLS layer could add random > padding of data and time, but I doubt this would help much. AFAIK, the TLS layer *does* bit-stuffing an

Re: client-side signature checking of Debian archives (Re: When should we https our mirrors?)

ple trying to update their systems against said exploit to spread even further? Well, this is exactly what would happen. We should not enable apt-transport-https by default until we have _really_ hardened and contained the apt transports. Now, hopefully I got all of that wrong and someone will set me straight. It would make me sleep better at night... -- Henrique de Moraes Holschuh

Re: libc recently more aggressive about pthread locks in stable ?

On Tue, Nov 8, 2016, at 15:39, Ian Jackson wrote: > Henrique de Moraes Holschuh writes ("Re: libc recently more aggressive > about pthread locks in stable ?"): > > That said, I am not going to propose any changes to the glibc blacklist > > at this time, unless new info

Re: Build a sort-of-systemd-dependent package on kfreebsd

s, and doubts about packaging corner cases are routinely handled there. -- Henrique de Moraes Holschuh

Re: call for participation - Debian contributors survey, 1st ed.

On Mon, 07 Nov 2016, Stefano Zacchiroli wrote: > On Mon, Nov 07, 2016 at 11:22:42PM +0100, Joerg Jaspert wrote: > > No logging or name is needed, with the set of questions in this survey > > one only needs a bit of knowledge of Debian and its people to identify a > > high amount of the survey taker

Re: libc recently more aggressive about pthread locks in stable ?

On Mon, 07 Nov 2016, Lucas Nussbaum wrote: > On 06/11/16 at 17:41 -0200, Henrique de Moraes Holschuh wrote: > > On Sun, 06 Nov 2016, Ben Hutchings wrote: > > > It's worth noting that TSX is broken in 'Haswell' processors and is > > > supposed to be disa

Re: libc recently more aggressive about pthread locks in stable ?

On Sun, 06 Nov 2016, Adam Borowski wrote: > On Sun, Nov 06, 2016 at 08:02:56PM +, Ian Jackson wrote: > > Henrique de Moraes Holschuh writes ("Re: libc recently more aggressive > > about pthread locks in stable ?"): > > > And what should we do about Debian

Re: libc recently more aggressive about pthread locks in stable ?

On Sun, 06 Nov 2016, Adrian Bunk wrote: > On Sun, Nov 06, 2016 at 05:41:34PM -0200, Henrique de Moraes Holschuh wrote: > > On Sun, 06 Nov 2016, Ben Hutchings wrote: > > > It's worth noting that TSX is broken in 'Haswell' processors and is > > > supposed

Re: libc recently more aggressive about pthread locks in stable ?

On Sun, 06 Nov 2016, Ben Hutchings wrote: > It's worth noting that TSX is broken in 'Haswell' processors and is > supposed to be disabled via a microcode update. I don't know whether > glibc avoids using it on these processors if the microcode update is > not applied. (Linux doesn't appear to hid

Re: libc recently more aggressive about pthread locks in stable ?

On Sat, 05 Nov 2016, Ian Jackson wrote: > Looking at the code, I think that gs in jessie is plainly violating > the rules about the use of pthread locks. On my partner's machine, Per logs from message #15 on bug #842796: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842796#15 SIGSEGV on __ll

Re: Intended MBF: maintainer scripts not starting on #!

On Sat, 05 Nov 2016, Santiago Vila wrote: > On Sat, Nov 05, 2016 at 04:35:16PM -0200, Henrique de Moraes Holschuh wrote: > > On Fri, 04 Nov 2016, Adrian Bunk wrote: > > > If I would report hundreds of "dpkg-buildpackage -A" FTBFS bugs against > > > stabl

Re: Intended MBF: maintainer scripts not starting on #!

On Fri, 04 Nov 2016, Adrian Bunk wrote: > If I would report hundreds of "dpkg-buildpackage -A" FTBFS bugs against > stable, would you consider that a valuable contribution to unhide problems? Packages in stable must build in stable. If a package from stable FTBFS in stable, then yes, you should

Re: Static linking and fPIC (Was: Re: "PIE by default" transition is underway -- wiki needs updating)

On Mon, 31 Oct 2016, Ian Campbell wrote: > On Mon, 2016-10-31 at 10:27 +0100, Jérémy Lal wrote: > > export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-pie > > ? > > Thanks, but that doesn't appear to help, I think the issue is to do > with the changed default in gcc rather than the hardening setting

Re: Planned NMU of w3-recs would use much archive disk space

On Thu, 27 Oct 2016, Marco d'Itri wrote: > On Oct 27, "Thaddeus H. Black" wrote: > > Unfortunately, without an NMU, this package would not be very > > useful to stretch users. > > > > I'd do what I could to trim the size, but this NMU will be big > > no matter what I do. > > > > Advice? Objecti

Re: "PIE by default" transition is underway -- wiki needs updating

On Wed, 26 Oct 2016, Adrian Bunk wrote: > On Wed, Oct 26, 2016 at 05:37:06AM +0200, Adam Borowski wrote: > > On Wed, Oct 26, 2016 at 12:37:18AM +0200, Andreas Cadhalpun wrote: > > > The current policy says: > > > "As to the static libraries, the common case is not to have relocatable > > > code" >

Re: Keysafe dynamic UID

On Sun, 23 Oct 2016, Guillem Jover wrote: > Right now I'm actually considering going over the archive and sending > patches to convert Debian-user and debian-user to _user… Make it active only for new installs, and you will have bypassed the most troublesome issue. Just be *extremely* careful to

Re: Bug#841113: ITP: extremetools -- tools for running processes under extreme uid and gid

ll and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique de Moraes Holschuh

Re: Update GnuPG failed

On Sat, 15 Oct 2016, Mechtilde wrote: > There is gpg version 2.1.15-4. > Unter Jessie all things are fine with gpg 1.4.18 > > Unter Stretch I have no access to my private key and the public keyring. > I only see the keys which incomes with the mails after the update > > What happens? The files of

Re: Is the reason for closing the bug 837459 appropriate here?

On Wed, 21 Sep 2016, Henrique de Moraes Holschuh wrote: > for that backport, and refering to bug #836459... Typo. Make that bug #837459... -- Henrique Holschuh

Re: Is the reason for closing the bug 837459 appropriate here?

On Wed, 21 Sep 2016, john.k...@vfemail.net wrote: > Is the reason for closing the bug 837459 appropriate here? The bug is still > here and no backported version. I believe it was appropriately closed, yes. #837459 is not a request for a backport. Instead, it is a bug about something that was alr

Re: Network access during build

On Thu, 08 Sep 2016, Russ Allbery wrote: > gregor herrmann writes: > > IIRC (I didn't re-read the whole bug log now) the intention in > > #770016 was indeed more than "not affect the build result" but > > "explicitly forbid any attempt to access the network because leak". > > > As a result policy

Re: Standards-Version field should be deprecated

On Thu, 08 Sep 2016, Moritz Mühlenhoff wrote: > We could reduce the policy checklist to issues not covered/coverable by > Lintian tests (which should be a rather small subset of overall policy > changes). Please don't. Feel free to annotate these, but don't remove them... I would rather not depe

Re: Thinking about a "jessie and a half" release

ss grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique de Moraes Holschuh

Re: Thinking about a "jessie and a half" release

t; -- The Silicon Valley Tarot Henrique de Moraes Holschuh

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

On Fri, 12 Aug 2016, Ian Jackson wrote: > Josh Triplett writes ("Re: use long keyid-format in gpg.conf (Re: Key > collisions in the wild"): > > I'd suggest moving directly to full fingerprints; from elsewhere in this > > thread, it sounds like the current version of gnupg has done so. > > What sh

Re: Please raise your opinion to package size and the given options to restrict it (Was: Bug#833388: ITP: metaphlan2 -- Metagenomic Phylogenetic Analysis)

On Thu, 04 Aug 2016, Holger Levsen wrote: > On Thu, Aug 04, 2016 at 09:30:19AM +0200, Andreas Tille wrote: > [...] > > > 2) When unpackaging the orig.tar.gz translating binary data to > > > text format and recompress using xz the tarball is "only" 265MB. > > > The transformation process

Re: Installer of Debian Stable allows to use btrfs for /, does it mean it's mature enough to use safely?

On Sat, 09 Jul 2016, german...@ya.ru wrote: > >If you are very conservative on these matters, your two choices are ext4 and > >XFS. > > I don't want XFS because it has weak journaling compared with "data=journal" > mode of ext3/4. The data=journal mode of ext4 is less stable than the default da

Re: Installer of Debian Stable allows to use btrfs for /, does it mean it's mature enough to use safely?

On Fri, 08 Jul 2016, german...@ya.ru wrote: > I value stability of a FS over other considerations like shiny new > features and performance. I know that Debian Stable includes only that Then, your case is pretty clear: stay away from brtfs. If you are very conservative on these matters, your two

Re: Gitlab and the BTS (was Re: Genesis of the git.d.o/gitlab.d.o confusion)

On Fri, 10 Jun 2016, Jonathan Dowland wrote: > I was wondering what the Gitlab proponent's thoughts are on how the Issue > tracker functionality of Gitlab should be used in a Debian context, > particularly in how it might intersect/interact/conflict with the BTS. You can enable/disable it per proj

Re: Bug#825821: ITP: neomutt -- NeoMutt is a place to gather all the patches against Mutt.

em. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique de Moraes Holschuh

Re: Bug#824884: netbase: should not recommend ifupdown

On Tue, May 24, 2016, at 13:03, Ansgar Burchardt wrote: > On Tue, 2016-05-24 at 11:43 -0300, Henrique de Moraes Holschuh wrote: > > On Tue, May 24, 2016, at 10:01, Simon McVittie wrote: > > > On Tue, 24 May 2016 at 09:08:11 -0300, Henrique de Moraes Holschuh > > > wrote:

Re: Bug#824884: netbase: should not recommend ifupdown

On Tue, May 24, 2016, at 10:01, Simon McVittie wrote: > On Tue, 24 May 2016 at 09:08:11 -0300, Henrique de Moraes Holschuh wrote: > > Whatever we do, we absolutely must bring up a fully configured loopback > > interface by default. > > Happily, our default init system alread

Re: Bug#824884: netbase: should not recommend ifupdown

to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique de Moraes Holschuh

Re: Packaging of static libraries

On Sun, 10 Apr 2016, Clint Adams wrote: > On Mon, Apr 11, 2016 at 12:13:20AM +0800, Paul Wise wrote: > > We should change policy and packaging tools such that static linking > > are not enabled by default and only enabled when there is a good > > reason to do so; when requested by users or when the

Re: Opt out style recommends

On Fri, 08 Apr 2016, Russ Allbery wrote: > So, where this goes wrong is the upower -> libimobiledevice4 dependency. > As you say, the dependency is correct (or at least correct-ish): we don't > want to dlopen everything and try to push all those patches upstream. But > this is the weakest link of

Re: support for merged /usr in Debian

On Sun, Jan 3, 2016, at 19:59, Christian Seiler wrote: > On 01/03/2016 10:53 PM, Henrique de Moraes Holschuh wrote: > > On Sun, Jan 3, 2016, at 18:35, Christian Seiler wrote: > >> My question would be: would those people here who have separate /usr > >> and aren't u

Re: support for merged /usr in Debian

and of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique de Moraes Holschuh

Re: support for merged /usr in Debian

working. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique de Moraes Holschuh

  1   2   3   4   5   6   7   8   9   10   >