Re: ruby-rails update destroy redmine issue number linking
Hi On Tue, 07 Jul 2020 09:36:20 +0200 "s.jaekel" wrote: > Package: ruby-rails > Version: 2:4.1.8-1+deb8u7 > Severity: important > Tags: upstream > > I updated the ruby-rails packages last week. > Since then i can use the also installed redmine (3.0~20140825-8~deb8u4) > no longer link tickets together. This was not a regular upload but an upload by the LTS team. I've CC'ed Sylvain (& LTS team), so hopefully someone can take a look at it. Best, Utkarsh signature.asc Description: OpenPGP digital signature
Re: ruby-rails update destroy redmine issue number linking
On 8/3/20 1:56 PM, Utkarsh Gupta wrote: > On Tue, 07 Jul 2020 09:36:20 +0200 "s.jaekel" wrote: >> Package: ruby-rails >> Version: 2:4.1.8-1+deb8u7 >> Severity: important >> Tags: upstream >> >> I updated the ruby-rails packages last week. >> Since then i can use the also installed redmine (3.0~20140825-8~deb8u4) >> no longer link tickets together. > > This was not a regular upload but an upload by the LTS team. > I've CC'ed Sylvain (& LTS team), so hopefully someone can take a look at it. I had snipped the bug report while CC'ing respective teams. Please see #964432 for the entire bug report. It is more verbose. Best, Utkarsh signature.asc Description: OpenPGP digital signature
Re: [Pkg-rust-maintainers] Backports needed for Firefox/Thunderbird ESR 78 in Buster/Stretch
On August 2, 2020 6:21 pm, Moritz Mühlenhoff wrote: > On Tue, Jul 28, 2020 at 10:17:35PM +0200, Emilio Pozuelo Monfort wrote: >> Hi, >> >> On 21/08/2019 07:45, Salvatore Bonaccorso wrote: >> > Hi Holger, hi Emilio, >> > >> > [dropping debian-devel list] >> > >> > On Mon, Aug 19, 2019 at 11:01:13PM +0200, Moritz Mühlenhoff wrote: >> >> On Tue, Jul 02, 2019 at 10:45:20PM +0200, Moritz Mühlenhoff wrote: >> >>> Hi, >> >>> Firefox 68 will be the next ESR release series. With the release of >> >>> Firefox 68.2 >> >>> on October 22nd, support for ESR 60 will cease. >> >>> >> >>> ESR 68 will require an updated Rust/Cargo toolchain and build >> >>> dependencies not >> >>> present in Stretch (nodejs 8, llvm-toolchain-7, cbindgen and maybe more). >> >>> Stretch was already updated wrt Rust/Cargo for ESR 60, so there's at >> >>> least no >> >>> requirement to bootstrap stage0 builds this time. >> >>> >> >>> If we want to continue to have Firefox/Thunderbird supported in >> >>> oldstable-security >> >>> after October, someone needs to step up to take care of backports to a >> >>> Stretch point >> >>> release before October 22nd (or in case of poor timing, we can also >> >>> release build >> >>> dependency updates via stretch-security). >> >> >> >> There hasn't been any visible movement on this, so unless someone steps >> >> up RSN, >> >> there'll be a headsup about the EOL in the next ESR 60 DSA, so that people >> >> have some advance warning. >> > >> > That would be really bad I guess both for users running stretch on >> > workstations for a while (we are affected for instance at work) and >> > for LTS as there were work so far by emilio to keep up firefox-esr and >> > thunderbird as well updated in jessie LTS. >> >> We are at this point again. ESR 68 will be EOL on September 22nd, when 78.3 >> comes out. We have some time still, but if we want FF and TB to keep being >> supported, we'll have to do some toolchain backports as usual. >> >> Has someone started to look at this? >> >> I have taken a quick look and it looks like we need rustc 1.41 and cargo >> 0.31. >> We currently have: >> >> rustc | 1.34.2+dfsg1-1~deb9u1 | oldstable >> rustc | 1.34.2+dfsg1-1| stable >> rustc | 1.44.1+dfsg1-1| unstable >> >> cargo | 0.35.0-2~deb9u2 | oldstable >> cargo | 0.35.0-2| stable >> cargo | 0.43.1-3| unstable >> >> We may need other deps after those (such as an updated cbindgen or other >> modules) or some packages in order to build those (possibly LLVM 9, I'm not >> sure >> yet). > > I don't have time to work on this, I'm away for large parts of August, > but I had a look at what is needed: > > We'll need LLVM 9 (which was a straight rebuild on buster in my test), > wasi-libc (also a straight rebuild with LLVM 9) and updated rustc. Updating > rustc will require some intermediate rustc/cargo uploads as we can't build > 1.41 with 1.34. all of those rustc versions should backport fine from their respective debian/* git tags with a backported LLVM, and as you said, backported wasi-libc for the more recent releases. I did the same for a Buster-based Debian downstream/derivative. 1.45 requires LLVM 10, not sure whether it's possible to build that with 9. LLVM 10 is a straightforward backport as well, so it's probably safer to go down that route if 1.45 is needed in Buster's lifetime. > We can also avoid these in the future by always bumping rustc to the > current version in point releases... building the needed rustc once with the bootstrap profile that downloads stage0, then re-building with that rustc might also be an option depending on policy? > I think we can reuse the same approach as before, by staging uploads > in -proposed-updates (or on stretch-security respectively) and then > configure the security chroots to use -proposed-updates until 10.6 > is eventually released. > > Cheers, > Moritz > > ___ > Pkg-rust-maintainers mailing list > pkg-rust-maintain...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers >
(semi-)automatic unclaim of packages with more than 2 weeks of inactivity (and missing DLAs on www.do)
hi, today there was one package unclaimed for LTS: - imagemagick (Markus Koschany) and none for ELTS. Emilio probably claimed too many packages, 4: - clamav - firefox-esr - libx11 - openjdk-8 There are three DLAs which have been reserved but not yet been published on www.debian.org: - DLA 2306-1 (reserved by Abhijith PA) - DLA 2303-1 (reserved by Markus Koschany) - DLA 2298-1 (reserved by Thorsten Alteholz) -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: ruby-rails update destroy redmine issue number linking
Hi, On 03/08/2020 10:38, Utkarsh Gupta wrote: > On 8/3/20 1:56 PM, Utkarsh Gupta wrote: >> On Tue, 07 Jul 2020 09:36:20 +0200 "s.jaekel" wrote: >>> Package: ruby-rails >>> Version: 2:4.1.8-1+deb8u7 >>> Severity: important >>> Tags: upstream >>> >>> I updated the ruby-rails packages last week. >>> Since then i can use the also installed redmine (3.0~20140825-8~deb8u4) >>> no longer link tickets together. >> >> This was not a regular upload but an upload by the LTS team. >> I've CC'ed Sylvain (& LTS team), so hopefully someone can take a look at it. > > I had snipped the bug report while CC'ing respective teams. > Please see #964432 for the entire bug report. It is more verbose. I tested with the latest redmine & ruby-rails in Stretch, and things appear to work fine (cf. attachment). Then I realized that this is about Debian Jessie which reached end-of-life a month ago, so the solution is to upgrade to Debian 9. Cheers! Sylvain
Re: ruby-rails update destroy redmine issue number linking
Hi Sylvain, On Mon, Aug 3, 2020 at 5:15 PM Sylvain Beucler wrote: > Then I realized that this is about Debian Jessie which reached > end-of-life a month ago, so the solution is to upgrade to Debian 9. Whilst I am totally fine by this suggestion, but still asking.. Would it make sense to fix this, since this upload was made just around the time Jessie was EOL'ed. Of course, I'd want people to upgrade, for sure, but in case they can't, I don't want to leave them high and dry. D'you think there's anything that could be done here? (or if that's too much to work on, maybe consider reverting the fixes?) Best, Utkarsh
Re: ruby-rails update destroy redmine issue number linking
Hi, On 03/08/2020 13:52, Utkarsh Gupta wrote: > Whilst I am totally fine by this suggestion, but still asking.. > Would it make sense to fix this, since this upload was made just > around the time Jessie was EOL'ed. > Of course, I'd want people to upgrade, for sure, but in case they > can't, I don't want to leave them high and dry. > > D'you think there's anything that could be done here? > (or if that's too much to work on, maybe consider reverting the fixes?) This version is now impacted by new security issues, such as CVE-2020-8163, so I would recommend upgrading anyway. There is no place to upload a new version (in particular, not in ELTS where neither rails nor redmine are supported), and as far as I understand s.jaekel could revert the security fixes manually, nearly a month ago. What are you suggesting, more precisely? If after upgrading to Stretch, and despite my working test today, the regression persists, I'll have a look at it. Cheers! Sylvain
Re: ruby-rails update destroy redmine issue number linking
Hi Sylvain, On Mon, Aug 3, 2020 at 6:02 PM Sylvain Beucler wrote: > This version is now impacted by new security issues, such as > CVE-2020-8163, so I would recommend upgrading anyway. There is no place > to upload a new version (in particular, not in ELTS where neither rails > nor redmine are supported), and as far as I understand s.jaekel could > revert the security fixes manually, nearly a month ago. What are you > suggesting, more precisely? What I was suggesting is no more relevant, you explained it in the above paragraph itself^ :) With regard to the above conversation(s), I am closing this bug for now. Please re-open if deemed necessary. Sylvain, Thanks for your pro-active work and reply here. Much appreciated! Best, Utkarsh
