Re: Use of the Build-Conflicts field

On Sun, Feb 17, 2019 at 07:44:29AM +0100, Tollef Fog Heen wrote: > I think it boils down to the question of «Are builds outside of a > minimal + build-essential + build-deps» supported?». If they're not, we > can just ignore the problem and deprecate the Build-Conflicts field > (since it has no us

Re: Use of the Build-Conflicts field

]] Russ Allbery > Tollef Fog Heen writes: > > > I think we should (over time) aim towards non-reproducible builds being > > release critical bugs, and I think «builds differently in an unclean > > chroot» is a class of non-reproducibleness we need to tackle («fails to > > build» is really just

Re: IBM POWER9 SIMD support? (Was: SIMDebian: ...)

Hi Kingsley, On Sat, Feb 16, 2019 at 11:43:46AM -0800, Kingsley G. Morse Jr. wrote: > My understanding is IBMs "POWER9" CPUs > > 1.) have SIMD instructions[1] and > > 2.) are used by the new, and very cool, open > *hardware* Talos II workstations[2], which > > 3.) already r

Re: Directory for .gir (gobject-introspection) files? (Multi-Arch)

Hi Simon, many thanks for taking the time to go through this bug report! Very much appreciated! On 2019-02-16 17:02, Simon McVittie wrote: > Multiarch-qualified directories under /usr/share don't seem like they make > much sense: the whole point of the $libdir/$datadir duality is that if > files

Re: Use of the Build-Conflicts field

Tollef Fog Heen wrote: > ]] Sean Whitton > > > There are two cases which we think that everyone would agree that there > > is a bug, but we are not sure that the bug would be considered to be RC. > > We are posting to -devel to see if, in fact, we do have a consensus that > > these bugs would be RC

Re: Recreating history of a package

On Sat, 2019-02-16 at 14:17 +0100, Guillem Jover wrote: > Hi! > > On Sat, 2019-02-16 at 12:22:04 +, peter green wrote: > > 2. Snapshot.debian.org is only offered over plain insecure http. For > >recent versions the packages can be verified against the > >Packages/Sources files which ca

IBM POWER9 SIMD support? (Was: SIMDebian: ...)

Hi Mo, I love your foot notes. My understanding is IBMs "POWER9" CPUs 1.) have SIMD instructions[1] and 2.) are used by the new, and very cool, open *hardware* Talos II workstations[2], which 3.) already run Debian. FYI, Kingsley [1] POWER9 https://en.wikipedia.org/w

Re: Use of the Build-Conflicts field

Tollef Fog Heen writes: > I think we should (over time) aim towards non-reproducible builds being > release critical bugs, and I think «builds differently in an unclean > chroot» is a class of non-reproducibleness we need to tackle («fails to > build» is really just a subset of «builds differentl

Re: Use of the Build-Conflicts field

]] Sean Whitton > There are two cases which we think that everyone would agree that there > is a bug, but we are not sure that the bug would be considered to be RC. > We are posting to -devel to see if, in fact, we do have a consensus that > these bugs would be RC, or not. > > (1) a package FTBF

Re: Directory for .gir (gobject-introspection) files? (Multi-Arch)

(Cross-posting to debian-devel, but with Reply-To to the bug) On Sat, 16 Feb 2019 at 09:32:16 +0100, W. Martin Borgert wrote: > at the moment, .gir files are placed under /usr/share/gir-1.0/. > However, such files can contain architecture specific content. > What would be the right directory? /usr

Re: Removal of icu-config (does your package still detect libicu)

Well, checking for libicu-dev in B-D of source package and libicu in binary packages is quite a simple test... -- Ondřej Surý > On 16 Feb 2019, at 14:40, Scott Kitterman wrote: > > My impression is the tests were cursory. If a package didn't FTBFS, it was > presumed to be OK. Fortunately h

Re: Use of the Build-Conflicts field

On Fri, Feb 15, 2019 at 08:59:41PM -0700, Sean Whitton wrote: > Use of the Build-Conflicts field is currently mostly optional, but Ian > Jackson and I have been working on text for Debian Policy that would > require its use in certain cases. See #824495 for the discussion. > > There are two cases

Re: Bug#922353: ITP: socket-activate -- Run a socket-activated daemon with minimal dependencies

Hi! On Fri, 2019-02-15 at 17:24:24 +0100, Andrej Shadura wrote: > Speaking of which, maybe it would also make sense to merge my changes > in? > > https://bitbucket.org/andrew_shadura/start-stop-daemon-isolate/commits/8646be59e3fde0b22f84a842ef5729a5de08fd3b This being

Re: Bug#922353: ITP: socket-activate -- Run a socket-activated daemon with minimal dependencies

Hi! On Fri, 2019-02-15 at 10:46:43 -0500, Daniel Kahn Gillmor wrote: > Control: clone 922353 -2 > Control: reassign -2 dpkg > Control: retitle -2 start-stop-daemon should support socket-activation via > the sd_listen_fds(3) convention > Control: severity -2 wishlist Thanks. > On Fri 2019-02-15

Re: Removal of icu-config (does your package still detect libicu)

My impression is the tests were cursory. If a package didn't FTBFS, it was presumed to be OK. Fortunately he provided a patch, so it is all better for postfix now. I just don't know what else might have been missed. Scott K On Saturday, February 16, 2019 12:47:34 PM Ondřej Surý wrote: > The

Re: Use of the Build-Conflicts field

On Sat, Feb 16, 2019 at 12:00 PM Sean Whitton wrote: > Use of the Build-Conflicts field is currently mostly optional, but Ian > Jackson and I have been working on text for Debian Policy that would > require its use in certain cases. See #824495 for the discussion. Personally, the main RC use-cas

Re: Recreating history of a package

Hi! On Sat, 2019-02-16 at 12:22:04 +, peter green wrote: > 2. Snapshot.debian.org is only offered over plain insecure http. For >recent versions the packages can be verified against the >Packages/Sources files which can in turn be verified with gpg but >older versions are more prob

Re: Recreating history of a package

On 12/02/19 13:26, Ian Jackson wrote: peter green writes ("Re: Recreating history of a package"): https://github.com/plugwash/autoforwardportergit/blob/master/pooltogit will take dscs in a pool structure and import them into git repos (one per source package) using dgit, building the history b

Re: Removal of icu-config (does your package still detect libicu)

The icu maintainer has properly communicated the change in the packaging for the packages I maintain and depend on libicu-dev (and filled RC bugs for it). I don’t know what has happened that postfix was missed. Ondrej -- Ondřej Surý > On 16 Feb 2019, at 10:33, Scott Kitterman wrote: > > Post

Removal of icu-config (does your package still detect libicu)

Postfix uses the presence of the icu-config binary to detect if libicu is available and thus if SMTPUTF8 support should be compiled in or not. Unfortunately, the icu package recently dropped this file, so when postfix was binNMU'ed it lost SMTPUTF8 (see #921075). I don't know if any other packa

Re: Bug#824495: Use of the Build-Conflicts field

On 2/16/19 7:08 AM, Scott Kitterman wrote: > On Friday, February 15, 2019 08:59:41 PM Sean Whitton wrote: >> Hello, >> >> Use of the Build-Conflicts field is currently mostly optional, but Ian >> Jackson and I have been working on text for Debian Policy that would >> require its use in certain case

Directory for .gir (gobject-introspection) files? (Multi-Arch)

Hi, at the moment, .gir files are placed under /usr/share/gir-1.0/. However, such files can contain architecture specific content. What would be the right directory? /usr/share/gir-1.0//? TIA & Cheers PS: This is related to #905715