Re: libffi libnettle transitions request
On Wed, 1 Jul 2020 at 01:31, Steve Langasek wrote: > > On Tue, Jun 30, 2020 at 05:28:17PM -0700, Steve Langasek wrote: > > On Mon, Jun 29, 2020 at 10:20:14AM +0100, Dimitri John Ledkov wrote: > > > To enable control flow protection (Intel CET) we need to kick of ABI > > > transition for libffi and libnettle, because trampolines / shadow > > > stack changes there change abi along with other changes that happened. > > > > libffi transition means rebuild of ruby python php haskell > > > llvm-toolchains guile > > > > I guess we should have opened with libffi transition, but oh well. > > > > Is it ok to proceed with libffi transition? It will be disruptive, due > > > to rebuilds triggering autopkgtests of all languages with bindings > > > effectively. > > > And there's already a libnettle transition ongoing in -proposed. Is that > > this one, or is it an unrelated one we should dump? > > Well, the nettle transition is entangled with the haskell transition, so > maybe not. The current libnettle transition has CET enabled, which i got going anyway. It looked small. -- Regards, Dimitri. -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: libffi libnettle transitions request
On Tue, Jun 30, 2020 at 05:28:17PM -0700, Steve Langasek wrote: > On Mon, Jun 29, 2020 at 10:20:14AM +0100, Dimitri John Ledkov wrote: > > To enable control flow protection (Intel CET) we need to kick of ABI > > transition for libffi and libnettle, because trampolines / shadow > > stack changes there change abi along with other changes that happened. > > libffi transition means rebuild of ruby python php haskell > > llvm-toolchains guile > > I guess we should have opened with libffi transition, but oh well. > > Is it ok to proceed with libffi transition? It will be disruptive, due > > to rebuilds triggering autopkgtests of all languages with bindings > > effectively. > And there's already a libnettle transition ongoing in -proposed. Is that > this one, or is it an unrelated one we should dump? Well, the nettle transition is entangled with the haskell transition, so maybe not. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: libffi libnettle transitions request
On Mon, Jun 29, 2020 at 10:20:14AM +0100, Dimitri John Ledkov wrote: > To enable control flow protection (Intel CET) we need to kick of ABI > transition for libffi and libnettle, because trampolines / shadow > stack changes there change abi along with other changes that happened. > libffi transition means rebuild of ruby python php haskell > llvm-toolchains guile > I guess we should have opened with libffi transition, but oh well. > Is it ok to proceed with libffi transition? It will be disruptive, due > to rebuilds triggering autopkgtests of all languages with bindings > effectively. And there's already a libnettle transition ongoing in -proposed. Is that this one, or is it an unrelated one we should dump? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: libffi libnettle transitions request
On Mon, Jun 29, 2020 at 10:20:14AM +0100, Dimitri John Ledkov wrote: > To enable control flow protection (Intel CET) we need to kick of ABI > transition for libffi and libnettle, because trampolines / shadow > stack changes there change abi along with other changes that happened. > libffi transition means rebuild of ruby python php haskell > llvm-toolchains guile > I guess we should have opened with libffi transition, but oh well. > Is it ok to proceed with libffi transition? It will be disruptive, due > to rebuilds triggering autopkgtests of all languages with bindings > effectively. $ ./misc-transition-script libffi7 libffi7.1 --dry-run|grep 'but not fixed' Package cpphs already present in groovy-proposed (but not fixed) Package darcs already present in groovy-proposed (but not fixed) Package ghc already present in groovy-proposed (but not fixed) Package gtk2hs-buildtools already present in groovy-proposed (but not fixed) Package haskell-aeson-diff already present in groovy-proposed (but not fixed) Package haskell-aeson-pretty already present in groovy-proposed (but not fixed) Package haskell-blogliterately already present in groovy-proposed (but not fixed) Package haskell-brainfuck already present in groovy-proposed (but not fixed) Package haskell-cabal-install already present in groovy-proposed (but not fixed) Package haskell-cracknum already present in groovy-proposed (but not fixed) Package haskell-dav already present in groovy-proposed (but not fixed) Package haskell-dbus-hslogger already present in groovy-proposed (but not fixed) Package haskell-debian already present in groovy-proposed (but not fixed) Package haskell-derive already present in groovy-proposed (but not fixed) Package haskell-doctest already present in groovy-proposed (but not fixed) Package haskell-ghc-events already present in groovy-proposed (but not fixed) Package haskell-gtk-sni-tray already present in groovy-proposed (but not fixed) Package haskell-hakyll already present in groovy-proposed (but not fixed) Package haskell-hindent already present in groovy-proposed (but not fixed) Package haskell-hjsmin already present in groovy-proposed (but not fixed) Package haskell-hledger already present in groovy-proposed (but not fixed) Package haskell-hledger-interest already present in groovy-proposed (but not fixed) Package haskell-hledger-ui already present in groovy-proposed (but not fixed) Package haskell-hoogle already present in groovy-proposed (but not fixed) Package haskell-hopenpgp-tools already present in groovy-proposed (but not fixed) Package haskell-hspec-discover already present in groovy-proposed (but not fixed) Package haskell-hsx2hs already present in groovy-proposed (but not fixed) Package haskell-jmacro already present in groovy-proposed (but not fixed) Package haskell-lambdahack already present in groovy-proposed (but not fixed) Package haskell-lazy-csv already present in groovy-proposed (but not fixed) Package haskell-markdown-unlit already present in groovy-proposed (but not fixed) Package haskell-mueval already present in groovy-proposed (but not fixed) Package haskell-pandoc-citeproc already present in groovy-proposed (but not fixed) Package haskell-pid1 already present in groovy-proposed (but not fixed) Package haskell-pretty-show already present in groovy-proposed (but not fixed) Package haskell-raaz already present in groovy-proposed (but not fixed) Package haskell-simple already present in groovy-proposed (but not fixed) Package haskell-skylighting already present in groovy-proposed (but not fixed) Package haskell-status-notifier-item already present in groovy-proposed (but not fixed) Package haskell-swish already present in groovy-proposed (but not fixed) Package haskell-tasty-discover already present in groovy-proposed (but not fixed) Package haskell-termonad already present in groovy-proposed (but not fixed) Package haskell-tldr already present in groovy-proposed (but not fixed) Package haskell-unlambda already present in groovy-proposed (but not fixed) Package haskell-wai-app-static already present in groovy-proposed (but not fixed) Package haskell-yaml already present in groovy-proposed (but not fixed) Package haxml already present in groovy-proposed (but not fixed) Package hscolour already present in groovy-proposed (but not fixed) Package lambdabot already present in groovy-proposed (but not fixed) Package llvm-toolchain-10 already present in groovy-proposed (but not fixed) Package mediawiki2latex already present in groovy-proposed (but not fixed) Package mighttpd2 already present in groovy-proposed (but not fixed) Package moarvm already present in groovy-proposed (but not fixed) Package pandoc-sidenote already present in groovy-proposed (but not fixed) Package taffybar already present in groovy-proposed (but not fixed) Package xmonad already present in groovy-proposed (but not fixed) $ Are we going to finish this haskell transition first? It's been in -proposed for 33 days already,
Re: please reset genext2fs to always failed on s390x
Done. On Mon, Jun 29, 2020 at 10:40:30AM +0100, Dimitri John Ledkov wrote: > https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#genext2fs > > It's always failed on all architectures, but s390x, where it's a Regression. > > Please reset the failed state to "always failed" on s390x for genext2fs. > > -- > Regards, > > Dimitri. > > -- > Ubuntu-release mailing list > Ubuntu-release@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-release -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: An updated version of proposed-migration is available to review
On Tue, Jun 16, 2020 at 06:07:09PM +0100, Iain Lane wrote: > Over the last few weeks, I've been working on rebasing our extensive > delta to proposed-migration. It's now at a state where it's ready for > others to take a look at. Please check out the output from a dry-run > (being re-run hourly from cron) > > > https://people.canonical.com/~ubuntu-archive/laney/proposed-migration/update_excuses.html > > https://people.canonical.com/~ubuntu-archive/laney/proposed-migration/update_output.txt Update on this: Testing found a couple of bugs. I think I've fixed them. They were mainly around arch:all handling. In Debian, these packages are usually built on separate buildds, and britney had made a couple of assumptions that relied on this. I'm thinking that I'll make the cut over on Thursday UK time, so please have a look at the output before then and check your .yaml-parsing scripts against the new output (location changed since my initial post; it's now .xz compressed) https://people.canonical.com/~ubuntu-archive/laney/proposed-migration/update_excuses.yaml.xz Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
