Re: Options for 64-bit time_t support on 32-bit architectures

* Simon McVittie: > On Fri, 19 Jul 2019 at 15:13:00 +0300, Adrian Bunk wrote: >> Remaining usecases of i386 will be old binaries, some old Linux binaries >> but especially old software (including many games) running in Wine. >> Old Linux binaries will still need the old 32bit time_t. > > Based on

Re: Congratulations BRIAN , Your Roof is Covered. Thank You!4Yq7

By the way, What I have in mind of this case, is to make sure that as many people as can be warned of this attempt on the lives of our Americans, are warned of the nature of these peoples own religions deranged atmosphere that is created within the institutional environment. I mean, I have only a

Re: Congratulations BRIAN , Your Roof is Covered. Thank You!4Yq7

Hi Debian; Yes, I will be happy to take more of the content out for you to further clear-up the vague (hidden) declusion by our governments effort to cover this story up. Right now, I am in the middle of a move and it will be difficult to get to until I am settled once again. I have to re-up the

Re: git & Debian packaging sprint report

Ian Jackson writes: > Ie I think you would consider this a blocker for you to use it as a > sponsor. Do you consider this a blocker for deployment at all ? No, it's just a regular bug (in something), at least to me. -- Russ Allbery (r...@debian.org)

Re: git & Debian packaging sprint report

Russ Allbery writes ("Re: git & Debian packaging sprint report"): > What I probably should have said from the start is that the place where > this information shows up that I personally care about is at: > > https://qa.debian.org/developer.php?login=rra&comaint=yes > > which shows the package

Re: file(1) now with seccomp support enabled [and 1 more messages]

Christoph Biedl writes ("file(1) now with seccomp support enabled"): > tl;dr: The file program in unstable is now built with seccomp support > enabled, expect breakage in some rather uncommon use cases. Thanks for this work and for the heads-up. PS: Did you really mean to send your first mail lik

Re: git & Debian packaging sprint report

Ian Jackson writes: > Russ Allbery writes ("Re: git & Debian packaging sprint report"): >> Ian Jackson writes: >>> I think in general those places are probably mistakes. But I'm not >>> aware of all of them. One way to look at this is that from the >>> archive's point of view this robot is a k

Re: Does debhelper prune empty directories?

Scott Talbert writes ("Re: Does debhelper prune empty directories?"): > On Fri, 19 Jul 2019, Scott Talbert wrote: > > I'm working on a package where I have a directory tree listed in the > > 'install' file with a destination directory. This source directory tree > > has > > a few empty subdirec

reflecting on the buster release cycle and RFF

Dear all, TL;DR: please give your constructive feedback on the buster release period, see the last paragraph. As the most recent member of the release team [1], I thought it could be a useful exercise to reflect on the release process and share it with you. As such a reflection goes, it should s

Re: git & Debian packaging sprint report

Russ Allbery writes ("Re: git & Debian packaging sprint report"): > Ian Jackson writes: > > I think in general those places are probably mistakes. But I'm not > > aware of all of them. One way to look at this is that from the > > archive's point of view this robot is a kind of sponsor. I don't

Re: trends.debian.net updated

Lucas Nussbaum writes ("trends.debian.net updated"): > I updated https://trends.debian.net . This is very cool and I wasn't even aware it existed! Yay! I have one quibble which I'm not sure how to address and, relatedly, a feature request. The feature request first. Would it be easy to add a c

Re: git & Debian packaging sprint report

Ian Jackson writes: > Russ Allbery writes ("Re: git & Debian packaging sprint report"): >> If so, I think that security model is roughly equivalent to the >> automatic signing of binary packages by buildds, so probably doesn't >> introduce a new vulnerability, but my understanding was that the >>

Re: git & Debian packaging sprint report

Hi. Not replying to things others have dealt with, but... Russ Allbery writes ("Re: git & Debian packaging sprint report"): > If so, I think that security model is roughly equivalent to the automatic > signing of binary packages by buildds, so probably doesn't introduce a new > vulnerability, but

Re: pdfproctools: fails to install (conflict with origami-pdf)

retitle 914333 origami-pdf & pdfproctools both ship /usr/bin/pdfmetadata reassign -1 src:origami-pdf,src:pdfproctools thanks On Thu, 22 Nov 2018 09:37:31 +0100 Jacek Politowski wrote: > pdfproctools fails to install due to conflicting "/usr/bin/pdfmetadata" file > which exists also in "origami-pd