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

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

Accepted iucode-tool 2.1-1 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 10 Nov 2016 23:27:52 -0200 Source: iucode-tool Binary: iucode-tool Architecture: source amd64 Version: 2.1-1 Distribution: unstable Urgency: medium Maintainer: Henrique de Moraes Holschuh <h...@debian.org> Changed-By: He

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

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 <h...@debian.org>

Accepted intel-microcode 3.20161104.1 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 09 Nov 2016 20:35:57 -0200 Source: intel-microcode Binary: intel-microcode Architecture: source amd64 Version: 3.20161104.1 Distribution: unstable Urgency: medium Maintainer: Henrique de Moraes Holschuh <h...@debian.

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

bts about packaging corner cases are routinely handled there. -- Henrique de Moraes Holschuh <h...@debian.org>

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

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 disabled via a micr

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 to be disabled

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

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

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

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

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

ss grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique de Moraes Holschuh <h...@debian.org>

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

Accepted amd64-microcode 3.20160316.2 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 09 Oct 2016 15:43:16 -0300 Source: amd64-microcode Binary: amd64-microcode Architecture: source amd64 Version: 3.20160316.2 Distribution: unstable Urgency: medium Maintainer: Henrique de Moraes Holschuh <h...@debian.

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

Accepted iucode-tool 2.0-1 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 12 Sep 2016 20:17:39 -0300 Source: iucode-tool Binary: iucode-tool Architecture: source amd64 Version: 2.0-1 Distribution: unstable Urgency: low Maintainer: Henrique de Moraes Holschuh <h...@debian.org> Changed-By: Henri

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

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

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

rkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique de Moraes Holschuh <h...@debian.org>

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

The Silicon Valley Tarot Henrique de Moraes Holschuh <h...@debian.org>

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

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

Accepted intel-microcode 3.20160714.1 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 21 Jul 2016 19:04:09 -0300 Source: intel-microcode Binary: intel-microcode Architecture: source amd64 Version: 3.20160714.1 Distribution: unstable Urgency: medium Maintainer: Henrique de Moraes Holschuh <h...@debian.

Accepted intel-microcode 3.20160607.2 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 08 Jul 2016 22:54:26 -0300 Source: intel-microcode Binary: intel-microcode Architecture: source amd64 Version: 3.20160607.2 Distribution: unstable Urgency: low Maintainer: Henrique de Moraes Holschuh <h...@debian.org> C

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

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

Accepted intel-microcode 3.20160607.1 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 23 Jun 2016 12:17:03 -0300 Source: intel-microcode Binary: intel-microcode Architecture: source amd64 Version: 3.20160607.1 Distribution: unstable Urgency: medium Maintainer: Henrique de Moraes Holschuh <h...@debian.

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

Accepted iucode-tool 1.6.1-1 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 05 Jun 2016 17:50:41 -0300 Source: iucode-tool Binary: iucode-tool Architecture: source amd64 Version: 1.6.1-1 Distribution: unstable Urgency: medium Maintainer: Henrique de Moraes Holschuh <h...@debian.org> C

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

the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique de Moraes Holschuh <h...@debian.org>

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

ring 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 <h...@debian.org>

Accepted iucode-tool 1.6-1 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 15 May 2016 10:08:05 -0300 Source: iucode-tool Binary: iucode-tool Architecture: source amd64 Version: 1.6-1 Distribution: unstable Urgency: medium Maintainer: Henrique de Moraes Holschuh <h...@debian.org> Changed-By: He

Accepted iucode-tool 1.5.2-1 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 30 Apr 2016 11:35:47 -0300 Source: iucode-tool Binary: iucode-tool Architecture: source amd64 Version: 1.5.2-1 Distribution: unstable Urgency: medium Maintainer: Henrique de Moraes Holschuh <h...@debian.org> C

Accepted autotools-dev 20160430.1 (source all) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 30 Apr 2016 07:52:30 -0300 Source: autotools-dev Binary: autotools-dev Architecture: source all Version: 20160430.1 Distribution: unstable Urgency: medium Maintainer: Henrique de Moraes Holschuh <h...@debian.org> C

Accepted intel-microcode 3.20151106.2 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 17 Apr 2016 12:38:12 -0300 Source: intel-microcode Binary: intel-microcode Architecture: source amd64 Version: 3.20151106.2 Distribution: unstable Urgency: medium Maintainer: Henrique de Moraes Holschuh <h...@debian.

Accepted amd64-microcode 3.20160316.1 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 10 Apr 2016 16:31:23 -0300 Source: amd64-microcode Binary: amd64-microcode Architecture: source amd64 Version: 3.20160316.1 Distribution: unstable Urgency: low Maintainer: Henrique de Moraes Holschuh <h...@debian.org> C

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

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

Accepted amd64-microcode 2.20160316.1 (amd64 i386 source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 19 Mar 2016 14:02:44 -0300 Source: amd64-microcode Binary: amd64-microcode Architecture: amd64 i386 source Version: 2.20160316.1 Distribution: unstable Urgency: critical Maintainer: Henrique de Moraes Holschuh <h...@debian.

Accepted iucode-tool 1.5.1-1 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 13 Feb 2016 20:21:12 -0200 Source: iucode-tool Binary: iucode-tool Architecture: source amd64 Version: 1.5.1-1 Distribution: unstable Urgency: medium Maintainer: Henrique de Moraes Holschuh <h...@debian.org> C

Re: support for merged /usr in Debian

where the shadows lie." -- The Silicon Valley Tarot Henrique de Moraes Holschuh <h...@debian.org>

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 using

Re: support for merged /usr in Debian

-- "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 <h...@debian.org>

Accepted intel-microcode 3.20151106.1 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 09 Nov 2015 23:07:32 -0200 Source: intel-microcode Binary: intel-microcode Architecture: source amd64 Version: 3.20151106.1 Distribution: unstable Urgency: medium Maintainer: Henrique de Moraes Holschuh <h...@debian.

Accepted iucode-tool 1.5-1 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 16 Oct 2015 23:41:35 -0300 Source: iucode-tool Binary: iucode-tool Architecture: source amd64 Version: 1.5-1 Distribution: unstable Urgency: medium Maintainer: Henrique de Moraes Holschuh <h...@debian.org> Changed-By: He

Accepted iucode-tool 1.4-1 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 03 Oct 2015 13:34:12 -0300 Source: iucode-tool Binary: iucode-tool Architecture: source amd64 Version: 1.4-1 Distribution: unstable Urgency: medium Maintainer: Henrique de Moraes Holschuh <h...@debian.org> Changed-By: He

Re: binNMU or reproducible builds (choose only one)

On Thu, 24 Sep 2015, Santiago Vila wrote: > You don't appreciate the beauty of simplicity. FOR binNMUs: * I do appreciate not triggering a libreoffice rebuild on the slow arches when a binNMU is required on amd64. AGAINST binNMUs: * I do appreciate multiarch not being broken by binNMU'd

Re: service failures should not fail dpkg installation [was: Re: promoting virtualbox-dkms to virtualbox pre-depends]

On Thu, 24 Sep 2015, Marvin Renich wrote: > How does failing the upgrade solve anything? The upgrade should only > fail if the failure of the service to start was because something in the > upgrade itself was broken; this is rarely the case. ... > What makes this even worse is that when

Accepted autotools-dev 20150820.1 (source all) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 11 Sep 2015 18:19:37 -0300 Source: autotools-dev Binary: autotools-dev Architecture: source all Version: 20150820.1 Distribution: unstable Urgency: medium Maintainer: Henrique de Moraes Holschuh <h...@debian.org> C

Re: [CTTE #741573] Debian Menu System

On Sat, 05 Sep 2015, Matthias Klumpp wrote: > 2015-09-05 3:49 GMT+02:00 Osamu Aoki : > > [...] > > >2. In addition to those changes, the Technical Committee resolves > > > that packages providing a .desktop file shall not also provide a > > > menu file for the

Re: Summary of the DebConf firmware discussion

and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique de Moraes Holschuh h...@debian.org

Re: Bug#796973: ITP: pseudo -- advanced tool for simulating superuser privileges

lie. -- The Silicon Valley Tarot Henrique de Moraes Holschuh h...@debian.org

Re: Security concerns with minified javascript code

. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique de Moraes Holschuh h...@debian.org

Re: Debian is not welcome on Microsoft Azure

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 h...@debian.org

Re: YAGF is a seriously screwed package

. -- The Silicon Valley Tarot Henrique de Moraes Holschuh h...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1436804350.487355.322493657.79569

Re: YAGF is a seriously screwed package

On Fri, 10 Jul 2015, Boris Pek wrote: But I am shocked to find this software being ported into stable packages, while it can do nothing. YAGF v0.9.3.2 works fine except one well known bug (see #746380). And this issue will be fixed in the next upload of the package. Please arrange for an

Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)

them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique de Moraes Holschuh h...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https

Re: git and https

On Fri, 29 May 2015, Russ Allbery wrote: Philipp Kern pk...@debian.org writes: Perfect is the enemy of good. Debian is already paying the protection money at this point and TBH I don't understand the resistance to add and promote the https:// variant of it. We can still switch to Let's

Re: when does debian 8.1 come?

where the shadows lie. -- The Silicon Valley Tarot Henrique de Moraes Holschuh h...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org

Re: when does debian 8.1 come?

them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique de Moraes Holschuh h...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https

Re: please use signed git commits (and tags)

On Tue, May 26, 2015, at 15:25, Vincent Bernat wrote: ❦ 26 mai 2015 14:38 -0300, Henrique de Moraes Holschuh h...@debian.org : A solution to this without history rewriting is to tag the commits you want to sign. You could tag any commit at any time, and sign that tag. Impractical

Re: please use signed git commits (and tags)

it can be duplicated/renamed at will. -- 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 h...@debian.org -- To UNSUBSCRIBE

Re: please use signed git commits (and tags)

are trusted, especially in remote copies? -- 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 h...@debian.org

Re: please use signed git commits (and tags)

. -- The Silicon Valley Tarot Henrique de Moraes Holschuh h...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1432572808.620926.277616689.2bf16

Re: git and https

access is not what you should be asking out of freedesktop.org, IMO. -- 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 h

Accepted iucode-tool 1.3-1 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 24 May 2015 19:31:23 -0300 Source: iucode-tool Binary: iucode-tool Architecture: source amd64 Version: 1.3-1 Distribution: unstable Urgency: medium Maintainer: Henrique de Moraes Holschuh h...@debian.org Changed-By: Henrique

Re: Bug#785480: ITP: bcg729 -- ITU G.729 Annex A compatible audio codec

checked. Has the situation changed? -- 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 h...@debian.org -- To UNSUBSCRIBE

Re: Q: why binary-log by systemd-journald is not enabled by default?

On Sat, 09 May 2015, Josh Triplett wrote: The on-disk persistent journal (/var/log/journal) is disabled because at the moment, Debian systems use syslog by default (via rsyslog), and enabling the persistent journal would result in two copies of log messages. Since the journal is capable of

Re: emacsen-common (was: Packages to install be default for Stretch)

users of the functionality provided by package A. -- 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 h...@debian.org

Re: Bug#784405: ITP: rnetclient -- Client to submit the Brazilian Income Tax Report to the Brazilian Tax Authority

, it looks like accepting this in Debian is a lot of risk for no real gain. -- 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 h

Re: Bug#784405: ITP: rnetclient -- Client to submit the Brazilian Income Tax Report to the Brazilian Tax Authority

, 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 h...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject

Re: Stetch goal: improvements to testing-proposed-updates / experimental?

of things. -- 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 h...@debian.org

Running webservices during build

from upstream), there is no problem. -- 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 h...@debian.org -- To UNSUBSCRIBE

Re: aptitude has Priority: standard, why?

grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique de Moraes Holschuh h...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https

Re: Bug#781765: ITP: graph-tool -- Python library for network (graph) analysis

grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique de Moraes Holschuh h...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https

Re: aptitude has Priority: standard, why?

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 h...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe

Re: Changing the ACL policy for alioth projects (Was: Unable to push debian-jr changes)

. -- The Silicon Valley Tarot Henrique de Moraes Holschuh h...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1427808796.569658.247542381.5afc2

Re: aptitude has Priority: standard, why?

On Tue, Mar 31, 2015, at 10:22, Stefano Zacchiroli wrote: On Tue, Mar 31, 2015 at 10:18:50AM -0300, Henrique de Moraes Holschuh wrote: apt-get is the simple tool everyone knows about, though. It also needs another simple tools like apt-cache to be really usable. It's tangential to the main

Accepted iucode-tool 1.2.1-1 (source amd64) into experimental

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 29 Mar 2015 20:53:03 -0300 Source: iucode-tool Binary: iucode-tool Architecture: source amd64 Version: 1.2.1-1 Distribution: experimental Urgency: low Maintainer: Henrique de Moraes Holschuh h...@debian.org Changed

Accepted iucode-tool 1.2-2 (source amd64) into experimental

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 17 Feb 2015 20:34:12 -0200 Source: iucode-tool Binary: iucode-tool Architecture: source amd64 Version: 1.2-2 Distribution: experimental Urgency: low Maintainer: Henrique de Moraes Holschuh h...@debian.org Changed-By: Henrique

Accepted iucode-tool 1.2-1 (source amd64) into experimental

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 14 Feb 2015 13:39:16 -0200 Source: iucode-tool Binary: iucode-tool Architecture: source amd64 Version: 1.2-1 Distribution: experimental Urgency: low Maintainer: Henrique de Moraes Holschuh h...@debian.org Changed-By: Henrique

Accepted intel-microcode 3.20150121.1 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 28 Jan 2015 20:03:20 -0200 Source: intel-microcode Binary: intel-microcode Architecture: source amd64 Version: 3.20150121.1 Distribution: unstable Urgency: critical Maintainer: Henrique de Moraes Holschuh h...@debian.org Changed

Accepted intel-microcode 3.20150107.1 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 18 Jan 2015 00:30:11 -0200 Source: intel-microcode Binary: intel-microcode Architecture: source amd64 Version: 3.20150107.1 Distribution: unstable Urgency: high Maintainer: Henrique de Moraes Holschuh h...@debian.org Changed

Accepted amd64-microcode 2.20141028.1 (amd64 i386 source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 18 Dec 2014 13:36:27 -0200 Source: amd64-microcode Binary: amd64-microcode Architecture: amd64 i386 source Version: 2.20141028.1 Distribution: unstable Urgency: medium Maintainer: Henrique de Moraes Holschuh h...@debian.org

Bug#772650: general: Debian could not use gateway in 169.254.0.0 ip range

On Wed, 10 Dec 2014, Maciej Kotliński wrote: Finally I found the easiest and trivial resolution of the problem. You just can set scope 0 with ip command. The interface with address 169.254.x.x gets scope link (253), so the packets won't be send outside NAT. Configuring interface with ip a

Bug#772650: general: Debian could not use gateway in 169.254.0.0 ip range

On Tue, 09 Dec 2014, Maciej Kotliński wrote: I have a NAT-ed network which uses 169.254.1.0/24 range (private/zeroconf range). The network has dhcp and gateway (169.254.1.1). From some time (probably few months) Debian Jessie is not able to use the gateway. This was never supposed to work in

Bug#772650: general: Debian could not use gateway in 169.254.0.0 ip range

On Tue, 09 Dec 2014, Maciej Kotliński wrote: It is possible to ping the gateway and other computers in 169.254.1.0/24 network. The packets are not routed by the nat. link-local addresses, such as 169.254.0.0/16 are unroutable. No traffic from/to link-local addresses is allowed to go through*

Bug#772650: general: Debian could not use gateway in 169.254.0.0 ip range

On Tue, 09 Dec 2014, Maciej Kotliński wrote: You don't understand what I mean. The gateway is forwarding packages! It is forwarding packages from Windows, Mac, and other Linux boxes in 169.254.x.x The gateway is doing something it was not supposed to do in the first place. Debian Jessie box

Re: Architectures where unaligned access is (not) OK?

On Fri, 21 Nov 2014, Sam Hartman wrote: I thought there was a flag bit you could set on x86 that causes unaligned access to trap there too. 1. CR0.AM must be set. 2. Ask For The Pain! i386: __asm__(pushf\norl $0x4,(%esp)\npopf); x86-64: __asm__(pushf\norl $0x4,(%rsp)\npopf);

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